MetaWayland: install an X io error handler

This way can detect X disconnections correctly, crash with a core
dump and reset the tty.
wayland: import weston-launch setuid launcher

To run mutter as a display server, one needs to acquire and
release the DRM master, which is only possible for root, so
we take advantage of weston-launch, a small setuid helper binary
written for the weston project. We import our own slightly
modified copy of it, because weston-launch only launches weston,
for security reasons.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
mutter-launch: simplify by removing features we don't need

Remove the ability to launch as a different user, which we don't
need because we're spawned by gdm or by the user manually on the
command line.
With that, we can also remove "security" checks.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
mutter-launch: make sure that the spawned binaries sees the right libraries

Being a setuid binary, our LD_LIBRARY_PATH is cleared by glibc at
startup, but we need the spawned binary to see it, otherwise
jhbuild doesn't work, so hardcode it using the configured libdir.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
mutter-launch: support spawning with stdin to /dev/null

If we don't have stdin connected to a terminal, and we don't see
the -t argument, assume the terminal we want is $XDG_VTNR

https://bugzilla.gnome.org/show_bug.cgi?id=705861
wayland: add TTY and DRM master management

Now that we have a setuid launcher binary, we can make use of
using the standard weston-launch protocol, through the socket
we're passed at startup.
We also add TTY management, to ensure the keyboard is in the
correct mode and the VT switching is in our control.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
wayland: add input device handling through mutter-launch

Use the new hook in clutter-evdev to ask mutter-launch for the
FDs of the input devices we need.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
Improve handling while VT switched

When we don't have the DRM master, there is absolutely nothing
we can do (no event processing, no video output), so emulate
the old X DRM lock with a nested GMainContext without sources.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
Add keybindings for switching VTs

Once mutter is started from weston-launch on its own VT, there is
no way to change VT again (for example to actually start an application),
because the keyboard is put in raw mode.
So introduce some keybindings mimicking the standard X ones (Ctrl+Alt+Fn)
that switch the VT manually when activated.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
Fix handling SIGTERM while DRM-locked

And at the same time, clean up the signal handling in the regular
case.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
Add a crash handler to restore the TTY and keyboard mode

If mutter crashes on secondary VT, it leaves you with a raw keyboard
that doesn't switch with Alt+FN and no way to get out. At least,
let's provide a decent error message that we crash and let's
restore everything to sane defaults.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
MetaWayland: redirect stdin/stdout/stderr when running on bare metal

We need to spawn background processes for gnome-session and friends,
so we need to make sure they don't try to read or write from our
terminal.

https://bugzilla.gnome.org/show_bug.cgi?id=705861
MetaWaylandKeyboard: use the new clutter-evdev support for xkbcommon

We need to track the full xkb_state to have the necessary information
to send to the clients, otherwise they may get confused and lock
or invert the modifiers. In the evdev backend, we just retrieve the
same state object that clutter is using, while in the other backends
we fake the state using what clutter is providing (which is a subset
of what X11 provides, which would be necessary to have full state)

https://bugzilla.gnome.org/show_bug.cgi?id=705862
MonitorManager: add a KMS backend

Using the new Cogl API to actually modeset (because we can't
use the DRM API directly without controlling buffer swap), we
can finally have a KMS monitor backend, which means full display
configuration when running on bare metal.
wayland: implement support for plugin modality

Calling XIGrabDevice has no effect under wayland, because the
xserver is getting events from us. Instead, we need to use our
own interfaces for grabs.
At the same time, we can simplify the public API, as plugins
should always listen for events using clutter.

https://bugzilla.gnome.org/show_bug.cgi?id=705917
MetaWaylandSeat: don't use use events to count pressed buttons

Use the modifier mask instead, as events can get lost if there
is a clutter grab or if some other actor is capturing events.

https://bugzilla.gnome.org/show_bug.cgi?id=706124
meta-wayland: intersect the damage region with the window size before applying

According to the wayland documentation, damage outside the
window size is ignored.
This happened with xwayland+wlshm (causing a GL error when calling
TexSubImage2D), probably due to not resizing the buffer
until we receive the corresponding X event.
Might also be an off-by-one in xwayland, as the window size did
not actually change.

Note: we might want to take the configure_notify path instead,
and keep the GL/clutter size consistent with wayland rather than
X, because in the end that's what matters for events and composition.

https://bugzilla.gnome.org/show_bug.cgi?id=706289
Set DISPLAY and WAYLAND_DISPLAY for dbus activated services and for autostarted apps

Call the appropriate method on gnome-session so that autostarted
and bus activated apps see the X server and wayland socket.

https://bugzilla.gnome.org/show_bug.cgi?id=706421
wayland: implement global and window keybindings

Synthetize XInput events from ClutterEvents in MetaWaylandKeyboard,
and pass them to the keybindings infrastructure for early handling,
so that we can activate them even if the currently focused window
is not an X11 one (or if there is no focused window, or we're
modal)
Stop messing with process groups and standard streams

We can be launched by gnome-session now, which implies:
1) gdb must attached from outside (and the Ctrl-C problem is gone)
2) stdin is /dev/null already
3) stdout is the journal, not the terminal

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