Add alpha-preserve attribute to ORA import/export

There's a more elaborate writeup about this issue from Drawpile's perspective here: https://docs.drawpile.net/devblog/2023/08/23/ora-alpha-preserve.html

Drawpile's got an analogous change ready: https://github.com/drawpile/Drawpile/commit/372114fefff757839acdb9d9ebb19ed27696b371

I'm also available on IRC as askmeaboutloom for bikeshedding the attribute name or any other needs.

On the <layer> element, there's now a new attribute alpha-preserve="true" if the layer has alpha preseve enabled. This allows that property to round-trip when saving and loading an ORA file, as well as compatibility with other programs that support alpha preserve on layers, which at the time of writing is Drawpile Programs that don't support it will just ignore the extra attribute.

Normal with alpha preserve is still saved as svg:src-atop, it was effectively the only blend mode that supported alpha preserve before. Reading-wise, the code handles both representations.

This also fixes the bug of any blend mode that's not known by the ORA spec with alpha preserve enabled getting saved as svg:src-atop as well, which effectively clobbered whatever blend mode was set with Normal. Instead, they now get saved as the proper blend mode with alpha preserve enabled.

Test Plan

1. Create a document that contains raster layers with the following layer setup:
   • Layer 6: Divide with alpha preserve
   • Layer 5: Divide
   • Layer 4: Multiply with alpha preserve
   • Layer 3: Multiply
   • Layer 2: Normal with alpha preserve
   • Layer 1: Normal
2. Save it to an ORA file.
3. Reopen the ORA file.

Previous behavior: Layer 4 restores without alpha preserve, Layer 6 restores as a Normal layer instead of Divide.

New behavior: all layers are restored with the proper blend modes and alpha preserve state.

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.