Ensure alignment, dominant-baseline and baseline-shift follow CSS-inline-3 and SVG2

I overhauled the baseline handling, so that we now 100% follow CSS-inline-3 and SVG 2.

• The old baseline handling was based on SVG 1.1, which in turn was based on XSL 1.1, where the idea was that there was one root baseline table that glyphs aligned to.
• Now, the glyphs align to their parent span, which in turn aligns to its parent span, and so forth. This simplifies the code greatly.
• Dominant baseline now also modifies the glyph origin, which in turn means those glyphs use the new baseline to apply SVG transformations to, as well as align to path. This is required by the SVG 2.0 spec.
• I moved the line relative stuff to use baseline-shift, as the css-inline spec currently says. Because this is somewhat vaguely defined, I write vertical-align when it is set. This is not exposed to the UI because its behaviour is in draft, and I had accidentally implemented it at the time because of vague wording in CSS-inline-3.
• Icons and tooltips have been added to all three properties.

In the above image, we lay out the hindi translation of our slogan from appdata.xml on a path. The top grey text is with default baseline, while the bottom black text is with hanging baseline. Note how the lower text avoids breaking the headstroke.

To Do:

• check for better icons. (later, currently getting feedback)
• write unittests.
• double-check that line wrapping is applied correctly.

Test Plan

• Make a text with different fonts and different font-sizes.
• Use dominant-baseline on the whole text to align all glyphs at once.
• Use alignment-baseline on a part of the text to align that chunk in specific.
• Use baseline shift on a part of the text to shift the whole thing. One caveat is bug:426607 which still bothers me.

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.
• Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

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.