per user keyboard state

[Antoine Martin]

The server has a single instance of the keyboard state for all users connected, see #1373, but some of the attributes should be per-client (ie: "layout-groups", see r17573) to support better key mapping with more exotic layouts.

[Antoine Martin]

See also #1027

[Antoine Martin]

Could fix #2030.

[Antoine Martin]

We can't control-c from the secondary client unless it uses the same modifier keys, the server log shows:

make_keymask_match: ignored as keynames_for_mod not assigned yet

[Antoine Martin]

r21174 fixes the ignored as keynames_for_mod not assigned yet problem without splitting the keyboard class.
This is probably too intrusive and risky to be backported.

The server keyboard object is actually already instantiated for every client in the input servers' parse_hello method: we call get_keyboard_config which returns an x11 KeyboardConfig object for x11 servers.

• some attributes need to be shared: keys_pressed is shared and passed in (a bit of a hack too).
• some attributes are definitely per-client: keycode_translation, xkbmap_mod_nuisance and xkbmap_mod_pointermissing, etc..
• for others, it is less clear: xkbmap_layout, xkbmap_variant and friends are currently only set by the first client, but we could consider merging the data from multiple clients so that all layouts are supported..

[Antoine Martin]

r21178 moves the "keyboard-sync" flag to the per-user keyboard configuration.

Still TODO:

• set_keyboard_layout_group - maybe this belongs elsewhere?
• keys_pressed unshare it? keep a per user version?
• owner attribute belongs elsewhere..

[Antoine Martin]

Can be dealt with as part of #1942