feat: implementation of Colrv1 fonts

[galkahana]

The following includes a fairly comprehensive implementation of Colrv1 fonts. This complements a move started in #224.

So this means - we got colorful Emojis :).

Most of the operators of Colrv1 are implemented (Note that Colrv0 is already supported with current release, which is how window's Segoe UI Emoji is providing its emojis). check out the Colrv1 (PDFWriterTesting\ColorEmojiColrV1.cpp) test for a demonstration. It uses a colrv1 version of Googles Noto font.

I did leave out a few things at at this point, and there's also some additional limitations for the implementation which will probably stay there:

• Some missing parts from the Colrv1 implementation:
  • I didn't implement the PaintComposite operator, meaning that i did a default src over blending (just drawing them on or top of each other, without special effects). kinda ran out of patience. Didn't see an actual glyph using it, but of course there could be some and this may effect some glyphs to appear incorrect. A sample might encourage me to improve this
  • In Sweep gradients i followed, i think, Skia in not really supporting any interim start and end angle, so only 0...360 sweeps are supported
• Support of those emoji is only provided via WriteText. It is NOT provided via Tj and other operators. I did this because Drawing emojis is not compatible with usages of Tj, which current model of usage respects. Drawing emojis requires drawing multiple glyphs and creates shades, and apply matrixes and the lot, which is way out of scope for a simple TJ which is supported by surrounding operators like Tm and such. I could have, however, do better in that if someone wants to use WriteText as one would use Tj, without setting color and position. If i do this, one can use WriteText interchangeably with Tj regardless of intended font usage, getting special considerations only for Emoji fonts and characters. usage might motivate me to do better.
• Drawing shades, with or without an alpha channels, makes use of PDF Patterns. If you know PDF Patterns you probably know that they are really bad for encapsulation and reuse. In essence - Patterns require to be provided with a transformation matrix that transforms the pattern graphic space to the default one. This effectively means that using them in things like reusable functions in your code or an xobject Locks them in place....and that they should be provided with that matrix. For simple usages of WriteText, when there's no matrix effecting the text postion/scale/whatever this is not a problem. however, if you wish to use such text in say a form that's place in multiple location, that can't be done. at least some will appear off...because a pattern is tie d to a particular transformation matrix. This is very limiting for potential usages. Also - at this point im not asking for being provided with that matrix in WriteText (or to set it up on something). If this is a problem for someone i'll sit down to at least write some method of being provided with a matrix. right now only the simple translation of WriteText is supported.

But lets not dwell on this. check out those lovely emojis:
ColorEmojiColrV1.pdf