This reverts commit 608f706a95.
Didn't end up using this in SDL3_mixer, and it's a super-awkward API if we
don't need it.
I _might_ bite the bullet and let people lock a physical audio device, though,
as I could see that being useful but less awkward for the same reasons I
originally wanted it.
Keymap construction is an expensive process, so keymaps are cached to facilitate fast switching, as they are static after initial construction, and do not need to be rebuilt every time.
This still logs backend choices, but we might use it for other things. For
example, what Android device is being used, or all the devices we enumerated,
etc.
Ideally this eventually logs all the stuff we often have to ask followup
questions about.
...so the backends don't have to do it.
Also added a stern warning about `org` being omitted, but leaving it as
allowed so as not to break existing apps (more than they are already broken,
at least).
Fixes#13322.
Only use the specified output if an exclusive mode is being used, or a position was explicitly requested before entering fullscreen desktop. Otherwise, let the compositor handle placement, as it has more information about where the window is and where it should go, especially if fullscreen was requested before the window was fully mapped, or the window spans multiple outputs.
When changing the text input mode on a window, only update the seats that currently hold keyboard focus on that window, otherwise, text input might be inadvertently enabled or disabled on a seat focused on another window.
Build all the available keyboard layouts at once; this adds a negligible bit of overhead when initially handling the keymap (which was already significantly lowered by previous commits), but reduces the later cost of changing layouts to just swapping a pointer.
Additionally, handling of unknown keysyms, particularly when dealing with virtual keyboards, is improved, as keys generating valid Unicode values with no corresponding scancode will be dynamically added to the keymap with reserved scancodes, allowing for proper round-trip lookup behavior.
Initializing the compose table is a very expensive operation, and only necessary if the locale envvar changed, which is often not the case when just changing the keymap, so don't destroy and recreate it whenever the keymap changes. The state only needs to be reset in this case.