PSD fill layers and color labels

An attempt to load some extra data from PSD files, mostly the fill-layers and the layer color labels.

This MR is going to languish a bit, because I did not generate the test files with photoshop, and I don't trust the program I generated them with (because that one also messes up generating the transparency masks, as well as some minor deviations elsewhere).

TODO:

• Save the data.

  • For the layer color labels, the problem here is that I am not smart enough and cannot figure it out. I've made PsdAdditionalLayerInfoBlock::writeLclrBlockExImpl, but when I use psdwrite and write 4 quint8, the resulting document doesn't load appropriately.

  • For the fill layers, the situation is more complex:

    1. Not all generators can be saved, our impex tools don't support informing about specific filters.
    2. Not all generator configs can be saved.
    3. The primary mask on our generators is actually part of the layer, while PS always has it as a transparency mask. So we'll need to check the presence of this.

    Overall, I am unsure where I want to start converting the generator layer config into an XML file

• Create proper test files for solid color fill.
  • I am 100% sure there's a color object for Lab and Grayscale in addition to the ones I've added in this MR. There's a slight chance there might be data for Pantone/HKS/TOYO, etc.
• Create proper test files for gradient fill.
  • Some of the gradients PS can make are loaded incorrectly by Krita. This needs more investigation (It's proly caused by segment gradients possibly having an offset which Krita's implementation does not support). (might be an error from the dodgy psd generation.
  • I am unsure about the transformations. Outside of that, the other thing that worries me is that the linear gradients have a different rotation point in Krita and PS.
• Create proper test files for pattern fill.
  • Again, unsure about the transforms.
  • Additionally, it seems there's something weird going on with loading embedded patterns...
• Create parsing and roundtrip unit-tests.
• I would really like to try and see if we can load the vmsk data. The primary mask on fill layers in PS are vector masks. We do kind of have the data buckets to store this as all our masks are KoSelection based, which can have vector data, though the layers and masks cannot have this data edited as a vector by the user right now. But I suspect that if artists don't touch the data it could roundtrip just fine, which isn't something to sneeze at.
  • I need test files for this.
  • This is, btw, how 'vector shapes' are stored inside PSD. (we might actually create a seperate code-path for when there's vector stroke data and then create a vector shape for that... depends on the availability of test files).
  • I will do this in a later MR.
• Of the 17 possible adjustment layers, Krita could potentially support 10. I do not want to do that in this MR, however. It's complex enough already.
• I'd like to do a bit more cleanup in psd.h, there's a few more structs (pattern, gradient color) there that we don't use because the asl parser takes care of it.

Test Plan

(Tell us how to test the changes you made.)

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!)
  • ./libs/image/tests/kis_asl_parser_test
  • ./libs/image/tests/kis_layer_style_projection_plane_test
  • ./libs/image/tests/kis_layer_styles_test
  • ./libs/image/tests/kis_layer_style_filter_environment_test
  • ./libs/image/tests/kis_asl_layer_style_serializer_test -- fails, unsure yet why.
  • ./plugins/impex/psd/tests/kis_psd_test is broken... QWARN : KisPSDTest::testOpenLayerStylesWithPattern() SAFE ASSERT (krita): "!localResources.contains(KoResourceSP())" in file /home/wolthera/krita/src/libs/resources/KisLocalStrokeResources.cpp, line 79
• 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.