Draft: Implement Text, Shapes and Guides for PSD

This implements three (technically 5~) things to PSD loading and saving:

1. Vector Masks – These get loaded as vector layers when possible, and otherwise loaded into the transparency masks’ shape layer. There’s still code for importing it into the transparency of the fill layer, though that is not used right now.
   • It might be worth it to distinguish a bit more between fill and vector layers. It seems old PSDs will always see vectors as fills with vector masks (there will be a user mask in addition to vmsk data) while modern PSDs distinguish between fills and vector masks by not writing a user-masks.
   • An argument against this is that while Krita internally supports vector masks and saves them appropriately, we don't have a way of editing these.
2. Vector Strokes.
3. Vector Parametric shapes (rects and ellipses) are also saved as vogk/live path shapes. We can load polygons but not save them. In either case PSD treats the live path data as primarily meta-data, so it should not be a huge deal if we can't save everything perfectly.
4. Basic text layer support, this is done by parsing the bytestream stored in TySh, and then treating this bytestream as ascii, which in turn is treated as ‘Carousel Object Model’ (aka: what PDF is written in). This can in turn be treated as a type of JSON. We also parse the txt2 dict, though we cannot save it in a way other PSD consumers can load.
5. Guides (also grids, technically, but those don’t get used, so we don’t save them)

PROBLEMS:

In order of severity:

1. We can only save vector shapes if there’s 1 in the vector layer. This is enough for roundtripping, but kinda annoying with anything beyond that. I guess we need some kind of ‘shape-layer explode’ thing?
2. Vector strokes ASL is stored with a ‘fill layer config’ inside. I kinda reworked the code already to have the catcher setup to be happening inside the struct, but I don’t understand how to switch between the different possibilities. I’m starting to wonder if the different structs should be unified or turned into a class with inheritance somehow?
   • Modern PS stores the fill inside the vscg tag, but it is written exactly the same as SoCo/GdFl/PtFl, with the first 4 bytes being the key of those fills, we load these now.
   • Similarly, storing vectorStroke fill data is hard due this, patterns are not supported.
3. It is apparently possible for unitFloats to be stored with different units, like for example, ‘#Pnt’ but also ‘#Pxl’, I’m not sure yet how to tackle this…
4. Text support is now decent, we can now read direction, writing mode, text-on-path, text-in-shape, fonts, colors and many properties.
   1. After asking on K-A, turns out there's a whole seperate dict inside Txt2. Depending on the PS version, it contains either string-keys or number-keys. Thankfully the inkscape devs have already figured out some values.
   2. We can now read and write both the per-layer TySh blocks. We can write both point and paragraph texts, various vertical-text related features. Unfortunately a psd with saved Txt2 don't load, due which I've chosen to disable txt2 saving for now, which means we cannot save the majority of opentype features (only ligatures, discretionary ligatures and small caps can be saved), nor can we save text paths. The problems are described in psd_layer_section.cpp.
5. Krita’s impex warning system has no toggle for guides, always warning the user they cannot be saved.

Test Plan

Load and save PSDs with text objects, some have been added to plugins/impex/psd/tests/data/sources

Formalities Checklist

• I confirmed this builds.
• I confirmed Krita ran and the relevant functions work.
• I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
• I made sure my commits build individually and have good descriptions as per KDE guidelines.
• I made sure my code conforms to the standards set in the HACKING file.
• I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.