Eliminate user copy/move ctors, assignment ops, and dtors

[mikebmcl]

The paper is going to impose the requirements that the implementation data types support copy and move semantics and will not include the requirement for these backend functions. So these will be automatically generated for the basic_* types and there should be no need for functions like
basic_figure_items<GraphicsSurfaces>::abs_new_figure::operator=(const abs_new_figure& other) and backend functions like GraphicsSurfaces::paths::move_abs_new_figure(move(other._Data)).

[mikebmcl]

@mikekazakov Would you mind taking this issue, eliminating them, and adding tests via static_assert using the relevant function templates in <type_traits>?

[mikekazakov]

So, we're removing copy_XXX and move_XXX and leaving create_XXX and destroy_XXX, right?

[mikebmcl]

removing destroy_XXX also. Only create_XXX is staying.

[mikekazakov]

This looks like a half-measure then - why not demand constructors and access methods too?

Also, on a second thought I'm not so sure that requiring various semantics from _data_types is a good approach. Right now it's possible to directly declare these as _data_types:

1. Raw pointers;
2. Handles/descriptors. (many GFX APIs do that)

The first one is actively used in RefImpl for abstracting implementation details. In some cases, like Cocoa/CocoaTouch, it's not a matter a taste - it's a question of being able to compile sources at all. Of course, such structs could be declared as showed below, but IMHO this brings an unnecessary layering.

struct _OutputSurfaceCocoa {
  struct PImpl;
  PImpl *impl;
  // copying, moving, destroying...
};
using output_surface_data_type = _OutputSurfaceCocoa;

Are there any other good ways to deal with dumb pointers and/or handles?

[mikebmcl]

The entirety of the design is effectively a set of contructors, access methods, etc., designed to allow the backend (such as cairo or CoreGraphics) to carry out the required functionality in the manner best suited to it without placing any requirements beyond input and result. What I realized is that there is no need for the copy, move, and destroy functions since the object itself must necessarily have them (if required) in order for that functionality to be carried out.

The cairo backend does this and, from what I've seen, the CoreGraphics backend also does it, via smart pointers (shared_ptr and unique_ptr). Essentially the only change is that rather than having the backend explicitly have these copy/move/destroy functions, instead their presence (whether implicitly generated or supplied by the user) is covered by static, e.g., that circle_data_type must be CopyConstructible and that image_surface_data_type must be MoveConstructible, which are terms that have special meaning within the C++ IS (20.5.3.1 [utility.arg.requirements] in C++17).

I'll take this issue. I mostly have my Mac setup to test CoreGraphics. I need to install brew and the relevant packages then should be all set (I already have MacPorts from my testing of cairo/Xlib in the pre-cmake build system). I can test it for all configurations once I finish that.