WIP: libei: specify a keymap behavior for how the device interacts

cc @ofourdan, @jadahl, @emersion because I wouldn't mind some thoughts on that

If we look at what xdotool does for sending key events, it expects that the keymap of the XTest device is intermixed with all other keymaps. So it sends key events to unset any modifier state first, then the intended sequence, then key events to restore that modifier state. This behavior is likely just there because X combines all keymaps, so it's not possible for xdotool to send key sequences unaffected by the state of other devices.

Let's add a configure request to decide the exact behavior. Where the behavior is 'individual' the keymap will be handled by EIS as an individual device, i.e. it's the job of the EIS implementation to reset the modifier mask before any key event so that the events come through correctly. Where the behavior is 'combined', the events can just be routed through the same path as all other devices and the modifier state is thus combined.

The use-case for sending key events that mingle with the state of other keyboards is probably niche but the combined behavior is easiest to implement. Long term I'd argue the EIS implementation should only support individual keymaps.

Thoughts? tbh, I'm considering requiring the 'individual' behavior in the EIS implemenation without a toggle but maybe there's some case where the combined behavior is actually intended? Like some software keyboard or something, maybe?

Note: this is just the API call and documentation to spur discussion, the full patch would obviously be more involved