Draft: Text property editing.

This is, as discussed, a start to allowing text property editing:

text-tool-demo-march-properties-2024-03-14_10.21.53.mp4

• KoSvgTextPropertyData struct to keep track of the data involved. I made this a struct in the end, so it can be extended more easily. There are a number of properties (primarily text-on-path related) that don't belong in KoSvgTextProperties, but should still be editable by docker. With a struct it'll be easier to add these once they become relevant.
• KisTextPropertiesManager to set data on canvas resource provider. This only does the paragraph level properties right now.
• Have KisTextPropertiesManager work for text-ranges in the text tool too.
• Make lager model out of KoSvgTextPropertyData.
• Make docker that reads the text properties.
• Somehow make changes text properties get set on text shape.
  • Text Tool
  • Shape Selection / Default tool
• Bugs:
  • Properly handle tri-state properties: Right now, displaying them in the docker means they're always, which means editing tri-state properties is a bit of a pain.
  • Similarly, sometimes the docker doesn't update correctly. Will need to investigate why.
  • Still need to check if a given property is enabled at all in the text properties. One of the problems here is that propertyIds are part of KoSvgText, but moving that enum is kinda fiddly.
• Allow property removal.
• Allow adding properties from a list.
• Fix up errors in rich text setting code.
  • Fix undos in the text tool.
  • Fix undos in the default tool.
• Allow configuring which properties are visible when.
• Make unit boxes work at all.
• Get all this to work in the appimage (doesn't right now because it can't seem to find the layouts in qdeclaritive)
• Figure out how to precisely handle paragraph properties.

Test Plan

• Select text objects with either the shape selection, shape editing or text tools, and there will be debug in the console indicating which properties are common and which are tristate (if selecting multiple).

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.