IME support for the text tool.

This MR implements basic input method support.

The pre-edit string (or compose string), is handled via an Undo command, and never added to the undo stack.

It is more or less complete, except for some problems:

• I'm having a hard time figuring out how https://doc.qt.io/qt-6/qinputmethod.html is supposed to be used: in particular I'm commiting, but when we switch texts it now resets because committing doesn't quite seem to do what I expected it to... (This seems to be a bug in IBUS)
• I am wondering whether QVariant inputMethodQuery(Qt::InputMethodQuery query, const KoViewConverter &converter) const override; in KoToolBase needs that converter, given that the tool always has access to the canvas which has everything we need. Similarly, virtual void updateInputMethodInfo() = 0; in KoCanvasBase.h is never implemented anywhere, and the function it is supossed to call is a QApplication function.
• Qt’s platform integration is very horizontal-tb focused, and thus may look somewhat glitchy. There’s nothing we can do here because Qt never implemented ImhNoTextHandles for android.
  • Looks like it eventually got implemented last september for Qt 6.
• Similarly, said input support uses Qt’s StandardKey for the behaviour of the floating menu, we might need to manually check for these KeySequences and activate the associated actions.
• The text shape tends to flicker when typing the input string because of the many undo/redo commands being used upon it. I wonder if we can block it from repainting while it is going through the input-method-event flow.
• We may need to change the fcitx dep (!1974 (comment 799162)).
• There's an issue that qApp->inputMethod->setInputItemTransform needs to be set whenever the canvas view transform changes, and I'm not sure how to go about that (https://doc.qt.io/qt-5/qinputmethod.html#setInputItemTransform)
• Qt doesn't have support for thick or double underlines, which means that all integrations set the background to opaque when they want to indicate the current pre-edit segment, which we therefore interpret as thick underline, as we can't support background.

Test Plan

• On Linux, you can setup either iBus (don’t ask me how, the KDE dialog is terribly confusing), and I think the Compose key should also work.
• On MacOS, the longpress on vowels should show a little menu with diacritics on said vowels: this is an input method.
  • From @freyalupen 's testing we came to the realisation that this only works in qt6, no clue if it can be backported.
• On Windows you're best off using the Japanese IME.
  • Unfortunately the windows platform integration doesn't support showing the seperate segments when using Japanese input. In the windows integration it only sets the 'segment before selection', 'selected segment' and 'segment after selection', even if the non-selected parts consist of multiple adjacent segments.
  • Windows support uses the XP-era IMM Api, instead of the Vista-era TSF api, and is thus not able to provide platform dedicated markup.
• For Android, all edits via the onscreen keyboard are supossed to be input method driven.

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.