Redesign keymap handling

Currently the API lets assigning a keymap at compositor level (which is running above QPA level), as in:

defaultSeat.keymap {
    layout: "us"
    options: "ctrl:swapcaps"
}

The code works, but it is not the best abstraction. Typically a keyboard layout settings are configured via tools in a desktop environment and then fetched by QPA plugin. As mentioned earlier, qt wayland compositor runs on top of QPA plugin, so naturally the xkb keymap would need to be passed from QPA to the compositor, instead of what the current API is doing.

Lets take as an example Liri OS, which runs qt wayland compositor on top of EGLFS QPA plugin + libinput. EGLFS currently does not support changing keymaps, adding support for this would be trivial: QWaylandKeymap should be renamed to QXkbKeymap and moved into QtGui. QPlatformIntegration should have new Capability -> XkbKeyboard and API for setting QXkbKeymap. QXkbKeymap should contain xkb_context/keymap/state. Compositor should access this keymap via QPlatformIntegration::xkbKeymap(). Liri OS keymap configuration UI should call QPlatformIntegration::setXkbKeymap() (instead of defaultSeat.keymap). With multi seat support this would need to be something like QPlatformIntegration::setXkbKeymap(device, keymap).

On X11, QPlatformIntegration::setXkbKeymap() should not be implemented. On X11 you should use your desktop environment to configure keymap. XCB plugin will get the keymap from X server when it changes. Compositor can fetch this keymap from QPlatformIntegration::xkbKeymap() the same way as with EGLFS plugin.

What about nested compositor (wayland qpa running in KWin)?

KWin compositor will send keymap to wayland QPA. The nested compositor which runs on this wayland QPA, can fetch the keymap from QPlatformIntegration::setXkbKeymap() as with the X11 and EGLFS cases from the above. QPlatformIntegration::setXkbKeymap() should not be implemented on wayland QPA plugin.

We can see that only platforms with no desktop environment, like EGLFS need to implement QPlatformIntegration::setXkbKeymap(). In all other cases we should use whatever the system has set. Note that all of these platform plugins and Qt in general currently does not support more then one keyboard. But it is also clear that API should be easy to adjust for multi-seat support in future.

(a) This way we could drop some code repetition and unnecessary recalculations in qt wayland source code.

What about qtwayland running on macOS?

On macOS QPlatformIntegration::Capability::XkbKeyboard won't be present as windowing system does not use XKB keymaps. What exactly to do on platforms without this capability remains to be decided. We can keep the code from (a), but separate it out (move out of sight), as macOS support is there only for development purposes.