wayland: don't use fork() and SIGCHLD to spawn processes

It is a very bad idea in a glib program (especially one heavily
using glib child watching facilities, like gnome-shell) to handle
SIGCHLD. While we're there, let's also use g_spawn_async, which
solves some malloc-after-fork problems and makes the code generally
cleaner.

https://bugzilla.gnome.org/show_bug.cgi?id=705816
wayland: move XWayland support code to its own file

Given that xwayland code is already split in meta-xwayland, it
makes sense to have there the implementation of the private
xserver protocol too.

https://bugzilla.gnome.org/show_bug.cgi?id=705816
MetaWayland: install an X io error handler

This way can detect X disconnections correctly, crash with a core
dump and reset the tty.
wayland: add TTY and DRM master management through weston-launch

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
wayland: add input device handling too

Use the new hook in clutter-evdev to ask weston-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
wayland: fix a compiler warning

Implicit declaration of memset
Add MetaCursorTracker, a new helper for tracking the cursor sprite

Under X, we need to use XFixes to watch the cursor changing, while
on wayland, we're in charge of setting and painting the cursor.
MetaCursorTracker provides the abstraction layer for gnome-shell,
which can thus drop ShellXFixesCursor. In the future, it may grow
the ability to watch for pointer position too, especially if
CursorEvents are added to the next version of XInput2, and thus
it would also replace the PointerWatcher we use for gnome-shell's
magnifier.

https://bugzilla.gnome.org/show_bug.cgi?id=705911
compositor: fix focusing the stage window

We can't use the X11 stage window, if clutter is not using the X11
backend (and even if it was, it would be bogus when the xwayland
server is not the one clutter is talking to). Instead, we introduce
the concept of "focus type", which we use to differentiate the
various meanings of None in the focus_xwindow field.
Rework and consolidate monitor handling between MetaScreen and MetaWaylandCompositor

Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from Cogl (which
in turn would read it from XRandR or KMS, depending on the backend).
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.
Also, now MetaWaylandCompositor listens for MetaScreen::monitor-changed
and exports the real configuration on the wayland socket.
Split monitor handling into an helper object

Create a new singleton object, MetaMonitorManager, which deals
with reading the XRandR configuration and in the future applying
the new one.
This is required because xwayland will not bind the xserver interface
until he has seen the current wl_outputs, so we can't wait
until MetaScreen is built to expose them.
wayland: apply stage size according to the monitor config

Still 1024x768, because we don't have a way to configure that,
but at least now it's hardcoded in the right place.
Introduce a new DBus interface for display configuration

This new interface will be used by the control center and possibly
the settings daemon to configure the screens. It is designed to
resemble a simplified XRandR, while still exposing all the quirks
of the hardware, so that the panel can limit the user choices
appropriately.

To do so, MetaMonitorMode needs to track CRTCs, outputs and modes,
so the low level objects have been decoupled from the high-level
MetaMonitorInfo, which is used by core and API and offers a simplified
view of HW, that hides away the details of what is cloned and how.
This is still not efficient as it should be, because on every
HW change we drop all data structures and rebuild them from scratch
(which is not expensive because there aren't many of them, but
at least in the XRandR path it involves a few sync X calls)
Add the write side of the DBus protocol too

This is just in the documentation for now, to attract wider feedback
before we start looking at how to implement this for real.
Extend the DBus XRandR protocol to expose cloning restriction

Turns out that even if two outputs say that they can be controlled
by a given CRTC, you can't configure them in the same CRTC unless
they are marked as "possible clones" one of the other.
This can further restrict the configuration options, so we need
to expose this limitation in the DBus API.