Toolkits need to know about both a latin layout to handle
accelerators which are usually defined like Ctrl+C and a
layout with the symbols for the language used in UI strings
to handle mnemonics like Alt+Ф, so we try to find and add
them in XKB group slots after the layout which the user
actually intends to type with.

We simply connect to IBus and tell it to switch engine when our
current input source setting is changed and an IBus engine is
specified there. The responsibility to make sure that this engine
actually exists on the IBus side is left to whoever writes the
setting.

At the same time, if an IBus engine is specified, we flip the setting
that backs the Gtk/IMModule XSETTING so that GTK+ applications get
notified to load the IBus input method when needed and go back to the
simple input method when IBus isn't required.

libgnomekbd/xklavier aren't a good fit to have the keyboard input
story that we want since they rely on implementation details of the
XKB protocol to provide users with a means to switch keyboard layouts.

Of note here is a) their reliance on XKB groups, of which there can be
only up to 4, to specify the layouts the user is able to switch
between and b) their reliance on XKB options to specify the keybinding
to switch layouts which is a restricted set and falls outside the
regular GNOME desktop wide keybindings management as it's implemented
entirely on the X server side.

This commit introduces the use of a shared GSettings schema from
gsettings-desktop-schemas which will be the storage for our new
concept of "input sources". Input sources are basically a tuple of
keyboard layout and, if needed, an IBus input engine that work
together to provide the user with working keyboard input.

As a start we only handle the keyboard layout for now. We do it using
roughly the same method that setxkbmap(1) uses which should allow the
users that want to specify their own XKB features (except layout) to
still do so outside of GNOME (e.g. in a session startup script).

This just happened to work by chance since both XkbStateNotify and
XkbStateNotifyMask are the same integral value.

XkbQueryExtension does everything we need here.

As instructed by Sergey V. Udaltsov:
https://bugzilla.gnome.org/show_bug.cgi?id=675674

We already have g_debug() here

https://bugzilla.gnome.org/show_bug.cgi?id=674221

So we can avoid using static variables in plugins

g_app_info_create_from_commandline() fails, and we never free
the error, so just don't use one.

They're not used in gnome-shell's status icon, no reason to
support them here.

Same code path as gnome-shell's version.

Instead of our own implementation.