Identify areas that might be extended in the future so they can be made forward-compatible

[mikebmcl]

There was concern that the path item types in the path_data::path_data_types type alias for a variant might need to be extended added to in the future, which would be an ABI break.

For path items, I don't think it's a problem since the core set of required instructions for path components is essentially fixed. Though I didn't think of it at the time, [paths.processing] in the paper itself demonstrates that all of the current path item types can be reduced to a core set of four:

• move;
• line;
• cubic Bezier (or quadratic); and,
• close path.

All others can be implemented either precisely or within a tolerable margin of error, e.g. Beziers can't exactly replicate circles or arcs, but they come close enough to be unnoticeable in the context of 2D raster graphics. Indeed, even Beziers could be eliminated though doing everything with Bresenham algorithms would be painful to implement in software.

Regardless, the request was to review the API and identify areas that we will or might want to make extensible so that they can be designed in a way that avoids the need for ABI breaks. Off we go!

[mikebmcl]

I'll be working on this, but if anyone else also wants to take a look through for these sorts of issues, that could certainly be helpful.