MetaBackgroundGroup: don't use clutter_actor_get_children()

In C code we can use ClutterActorIter and avoid allocating a GList.
Improve handling of warnings and criticals

Instead of squash everything into "window manager warnings",
let the glib log framework handle Mutter (and other) warnings.
META_USE_LOGFILE support is preserved by rerouting warnings
in our domain.
This way we get process name and PID, nice CRITICAL/WARNING/ERROR
instead of a number, and the ability for plugins to override
the log handler. For example gnome-shell uses this to output
a JS backtrace.
main: remove a lot of code to handle wrong theme config

mutter has a hard dependency on gnome-themes-standard, which
provides the Adwaita theme. If that is not satisfied, it is
a distribution problem, so we can just fail (and let the
automatic smoketests notice it)
main: use glib to handle sigterm

We can remove a lot of code with that
Strip whitespace in warnings and errors

The old log system did not add a newline at the end, but the new
one does, so don't add another one.
MetaWindowActor: fix reference counting issue

We need to use g_signal_connect_object(), rather than g_signal_connect(),
because the window actor can be destroyed before the window emits
the final notify::appears-focused inside unmanage, if the plugin
decides that it doesn't want to animate the destruction (which
happens with dialogs and the default plugin)

https://bugzilla.gnome.org/show_bug.cgi?id=706207
Rework and consolidate monitor handling in MetaScreen

Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
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.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
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)

https://bugzilla.gnome.org/show_bug.cgi?id=705670
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.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
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.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
DisplayConfig: add the write side of the API

Implement ApplyConfiguration in terms of XRandR calls.
Error checking is done before actually committing the configuration.

If mutter is using one of the other monitor config backends, an
error is reported and nothing happens.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
Reverse handling of XRandR events between Screen and MonitorManager

Now MonitorManager does its own handling of XRandR events, which
means we no longer handle ConfigureNotify on the root window.
MetaScreen reacts to MonitorManager::monitor-changed and updates
its internal state, including the new size.

This paves the way for doing display configuration using only
the dummy backend, which would allow testing wl_output interfaces.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
DisplayConfig: make the dummy backend writable

Add a number of dummy outputs and modes to the dummy backend,
and implement the writing bits.
The only visible effect is that you can change the screen size,
which resizes the output window.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
default plugin: add a random color background on each monitor

Instead of a full white background, make one with a random color.
This way the different "monitors" are visible and it's easier
to debug the DBus API.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
MonitorManager: fix handling of output transform

Read the current transform from XRandR, and expose the transforms
that are really supported on the bus.
The dummy backend now advertises all transforms, since it doesn't
actually apply them.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
MonitorManager: inherit directly from DisplayConfig instead of handling signals

This way we can handle properties too.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
MonitorManager: add support for DPMS levels

To the XRandR and dummy backend (and as usual the dummy backend
has no effect)

https://bugzilla.gnome.org/show_bug.cgi?id=705670
MonitorManager: add support for persistent monitor configurations

Add a new object, MetaMonitorConfig, that takes care of converting
between the logical configurations stored in monitors.xml and
the HW resources exposed by MonitorManager.
This commit includes loading and saving of configurations, but
still missing is the actual CRTC assignments and a default
configuration when none is found in the file.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
MonitorConfig: add CRTC assignment

Ripped off libgnome-desktop, trimming the parts that checked
that the configuration was plausible, as that should be done
in gnome-control-center before asking mutter for a change.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
MonitorConfig: add support for default configurations

Activate the presentation bit on new hotplugged monitors, while
making a fully extended setup when running for the first time.

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