[wayland][input] Add xkb compose and dead-keys support

[enen92]

Description

This pull request adds support for compose keys (those created from pressing key combinations using dead keys) to xkbcommon - wayland implementation (read more about this here).
This has bugged me for a while, using an attached keyboard you can't input the deadkey unicode symbol (usually used in passwords like ~,´, ^, etc) nor the key composed combinations (e.g. ~+a = ã).

Along with support for the key composer in xkbcommon, this PR also modifies the GUIEditControl to allow for user feedback while composing keys - similar to what happens when you use regular applications like the terminal or a text input in the browser:

• If the control is flushed and waiting for input it has a blinking cursor (|)
• If the control is composing a key it shows the current dead key unicode codepoint sequence as the cursor value without blinking
• After composing a key, the cursor buffer is flushed to the actual input while the cursor is reset to normal state (blinking |).

See more about this in the video screencast below.

All this is guaranteed by a new set of events (XBMC_KEYCOMPOSING_COMPOSING, XBMC_KEYCOMPOSING_FINISHED, XBMC_KEYCOMPOSING_CANCELLED) that then map to actions that end up consumed by the GUI layer.

Unfortunately this ended up being a bit involved and is also platform dependent. Regardless, it sets the blueprint for other platforms to implement something similar. I may have a crack at other platforms (namely other linux implementations and android) later if this one goes in.

Most of the complexity comes from the fact that to mimic the composed-key sequence cancellation behaviour we all are used to (replaying the sequence plus the key/unicode that lead to the cancellation) requires that state is stored outside of the composer. I am using the control cursor to track the "state": when the composing cancellation event occurs, the control flushes the cursor buffer (the key sequence until then) to the actual control input (to which is later appended the cancellation key).

Motivation and context

Fix #23828

How has this been tested?

Runtime tested on Linux, wayland qwerty keyboard with a portuguese layout.

What is the effect on users?

Dead key / Composed keys should now be supported when using keyboards just like other applications

Screenshots (if appropriate):

https://www.youtube.com/watch?v=1y147A87hAc

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[sundermann]

Can't say much on the GUI stuff. The wayland stuff seems fine, except for that this feature should be optional as the compose map is not available on webOS. For the same reason, I couldn't test it unfortunately. I'll look if there's something about the webOS side to fix this because dead keys appararently work on the webbrowser