wayland: Add support for text-input-unstable-v3

[flibitijibibo]

This was my last attempt to get the official text input protocol working with the Wayland driver. It was eventually abandoned because the protocol just doesn't work at all, based on my testing of both this patch as well as the official wlroots example. It's a really simple API so I'm not sure what we could be doing wrong. On all the desktops I could test against, all I get is an enter event with nothing else following it. Luckily all this does is add support for spawning the OSK, which end users can technically do themselves, and setting the text input rectangle, which only matters for windowed mode where we can't just assume the window is pinned at 0,0 like in fullscreen mode. See #4360 (comment) !

Fixes #3578.

[flibitijibibo]

Good news, I finally figured out how to make this work! The bad news: This protocol literally only works with the OSK. 🤦

We can't use this at all because we really need to be able to read keyboard text events, but at the same time if we try to use our built-in IME support we're basically accessing ibus twice at once, which I don't even think is technically possible without possible resource-is-busy errors. Not going to lie, between this and the bug I found in StartTextInput the whole thing feels like a pretty spectacular failure on the server side.

Will keep this open in the hopes that v4 will make this viable to use with both physical and on-screen keyboards, until that happens we're better off using our own IME implementation.

[flibitijibibo]

I finally figured this mess out!

So, to confirm: text-input-unstable-v3 only works with the on-screen keyboard... but there's nothing that says we can't check both on-screen text events and physical key presses, which in Wayland don't appear to overlap in any way.

With that in mind I redid this patch to merge the two together, and it appears to not only work perfectly, but also seems to have fixed some things that didn't work before! I was able to test dynamically-swapped QWERTY, AZERTY, and Kanji input which didn't work at all before, and the input rectangle is in the right spot now!

One interesting detail: Because the text input protocol handles on-screen support, I added a HasScreenKeyboard implementation that returns true when the protocol is available. This is a slight divergence from X, but as far as I know you were always meant to be explicit about Start/StopTextInput calls anyway (in FNA's text input extension we require this for all targets).

[flibitijibibo]

Apologies for all the force-pushes, had to cover an interesting case where empty editing events would get fired on focus events. The IME backends are still merged, mostly, it just avoids using the manual SDL_IME connection in favor of the protocol when available.

Everything's been cleaned up and re-tested with various layouts and input types, so this should be good to merge.