Refactor paint server data so the renderer works from data · 28f378d3

This allows the paint server code to be unit tested in later versions. There are some limitations
to this refactoring including use of virtual functions instead of casting so we can use templates
in renderers.

ll SPObjects must implement their virtual functions, so the base classes all return empty objects
where possible and this pushed the design in a certain direction for some calls.

 * Move sp-gradient spread, units and vector to sp-paint-server-data.h
 * Move mesh gradient patches data from display/drawing-paintserver to sp-paint-server-data
 * Allow SPPaintServer to be used as a template class in a renderer by providing data from sp-paint-server-data in a consistant way from the base class using virtual functions.
 * Add getPaintType and enum class to decide what type of paint server we have instead of cast
 * Add SPGradient virtual for gathering geometric gradient data for Lienar and Radial gradients
 * Add SPMeshGradient virtual for gathering mesh patches data for the Mesh gradient
 * Pack gradient geometric data into SPGradientVector and return in getGradientVector
 * Harmonize const and API between Mesh Gradients and Linear/Radial Gradients
 * Move add create_drawing_paintserver calls to display/drawing-paintserver in a single call
 * Remove `mg` MeshGradient pointer from MeshArray and remove back-linking. This indicates bad
   API design for some of these calls as the functions used mg and had little to do with the MeshArray
   but for now we just push the MeshGradient object back in as an argument.
 * Change drawing-paintserver constructors to take paint-server-data objects instead of individual arguments.

Add Alpha color space · 8ca72a9c

This color space allows surfaces to be converted to luminosity masks
and varius other useful alpha related filtering for the new rendering
engine.

We use lcms2 to hold the gray scale profile for quicker conversions.

The transform-cms is modified so it can cope with outputs which do
not have an allpha channel of their own. Tests for this are added.

New image pixel access and pixel filters · bd1a6bc0

To support more color channels, and greater flexibility in our rendering
engine, this new code impliments a new API for accessing pixel data in a
cairo surface and expands it's capabilities so that they can work with
floating point pixel data as well as CMYKA (5 channel) interpolations.

The new interface makes heavy use of compile time templating for channel count
and cairo surface formats.

The primary use of this API is for filters. Each filter which depends on
non-cairo functionality is recoded to use this new API and split out from
their svg filter primitive and display object files so they can be unit tested.

Threading and dispatch pool are held as light copies until the refactoring is
completed and we can copy them to a central utility instead.

Assistance from PBS (squashed):

* Use requires instead of run-time checks.
* Use more modern _v/_t instead of ::value/::type.
* Fix const T* memory() calling itself in infinite loop.
* Make some functions static (_primary_pos, _bilinear_interpolate).
* Make _transform std::optional.
* Convert G_BYTE_ORDER == G_LITTLE_ENDIAN to if constexpr, revealing
  missing glib.h header.
* Use safemod for wrapping.

Build surface management engine · da7dfd77

To contain the multiple cairo surfaces and integrate with the pixel access code
a new Surface class is made that stores references to cairo surfaces.

PixelAccess objects of the right format can be run with filters to control the
surface at a pixel by pixel level.

A host of new tests are adding for each of the filters to make sure PixelAccess
integration is correct for each one of them.

Other Changes

 * Add forward declaration to colors API to smooth importing

Build context drawing engine · beeee41e

We wrap the cairo context with our own multi-context engine
which keeps track of the color space, can paint multi-surface
CMYK rasters onto each other as well as translate between
Inkscape geom, path objects to cairo instructions.

Added many tests for each of the functionalities in cairo context
drawing.

Add README to explain the local code structures.

Add Drawing Filter stack to render SVG Filter Primitives · 93413e02

The stack mostly backs onto PixelFilters, but also onto the Surface
and Context where upstream functionality can provide the output.

The ColorSpace for the filter primitives are tied into the rendering
process so filters are rendered in the correct space.

Drawing options are refactored to be more concise for future use.

Copy of display/drawing* code · a93c3c89

This copy from display allows the differences to be seen more easily.

display/drawing* -> renderer/drawing/drawing*
display/surface* -> renderer/drawing/drawing-area* (might not be needed)
display/tags* -> renderer/drawing/drawing-item-tags*
display/nr-style* -> renderer/drawing/drawing-style*

Refactor DrawingItem and the rest of the Drawing stack for new rendering engine · 4fad4dca

The process used for this refactoring was a light touch on the logic. But
the namespaces, and somme processes that were incompatible with the new
surface and pixel filters had to be changed.

The RenderContext was changed to DrawingOptions to better express what it is
and the various options from filters and other parts of the pipeline were
added so they aren't being passed around in addition.