Use $XDG_CONFIG_HOME/xkb as first lookup path for the XKB context

This patch adds $XDG_CONFIG_HOME/xkb as first lookup path for XKB descriptions. This is in addition to the usual /usr/share/X11/xkb and allows users to place custom keyboard layouts into that directory. This is particularly useful with the future libxkbcommon support for include directives in rules files as it allows for very simple additions of custom keyboard mappings. Not quite as simple as xmodmap but with full scope of XKB behind it.

Specifically, the rules file could look like this:

$ cat $XDG_CONFIG_HOME/xkb/rules/evdev
! option = symbols
  foo = custom(foo)

! include %S/evdev

$ cat $XDG_CONFIG_HOME/xkb/symbols/custom
partial alphanumeric_keys 
xkb_symbols "foo" {
    key <TLDE> {        [      VoidSymbol ]       };
};

The name evdev is used because it is effectively hardcoded everywhere now and custom rule sets are not always possible. The above config defines a new option foo that overrides the tilde key to do nothing. The ! include statement loads the evdev rules from the system directories (%S), so that ruleset is the new option + all the default evdev rules.

The new option can then be loaded with:

gsettings set org.gnome.desktop.input-sources xkb-options "['foo']"

(more work is needed to get this to show up in the various GUI tools)

libxkbcommon has already added $XDG_CONFIG_HOME/xkb as first lookup path. However, being a library it uses secure_getenv() which returns NULL where capabilities are set. In mutter's case, the rt-scheduler requires CAP_SYS_NICE, already enabled on Fedora 31. Thus XDG_CONFIG_HOME and HOME are always NULL on mutter/Wayland and we need to add this ourselves in mutter. For other consumers with empty capabilities, the libxkbcommon change is sufficient.

I took a wild stab at where to put the centralised xkb context initialisation function, that one can obviously be moved anywhere.

cc @carlosg

[edit: clarification, initial report blamed this on setuid root but by cap_sys_nice]