input: Add support for making libxkbcommon optional

input: Add support for making libxkbcommon optional

In embedded environments, devices that appear as evdev "keyboards" often
have no resemblence to PC-style keyboards.  It is not uncommon for such
environments to have no concept of modifier keys and no need for XKB key
mapping; in these cases libxkbcommon initialization becomes unnecessary
startup overhead.  On some SOC platforms, xkb keymap compilation can
account for as much as 1/3 - 1/2 of the total compositor startup time.

This patch introduces a 'use_xkbcommon' flag in the core compositor
structure that indicates whether the compositor is running in "raw
keyboard" mode.  In raw keyboard mode, the compositor bypasses all
libxkbcommon initialization and processing.  'key' events containing the
integer keycode will continue to be delivered via the wl_keyboard
interface, but no 'keymap' event will be sent to clients.  No modifier
handling or keysym mapping is performed in this mode.

Note that upstream sample apps (e.g., weston-terminal or the
desktop-shell client) will not recognize raw keycodes and will not react
to keypresses when the compositor is operating in raw keyboard mode.
This is expected behavior; key events are still being sent to the
client, the client (and/or its toolkit) just isn't written to handle
keypresses without doing xkb keysym mapping.  Applications written
specifically for such embedded environments would be handling keypresses
via the raw keycode delivered as part of the 'key' event rather than
using xkb keysym mapping.

Whether to use xkbcommon is a global option that applies to all
compositor keyboard devices on the system; it is an all-or-nothing flag.
This patch simply adds conditional checks on whether xkbcommon is to be
used or not.

v3 don't send zero as the file descriptor - instead send the result of
opening /dev/null

v2 by Rob Bradford <rob@linux.intel.com>: the original version of the
patch used a "raw_keycodes" flag instead of the "use_xkbcommon" used in
this patch.

v1: Reviewed-by: Singh, Satyeshwar <satyeshwar.singh@intel.com>
v1: Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>