Always map the client and frame windows

Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.

However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.

I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.

Remove this now.

The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. In the future, we might want to
show previews of shaded windows in the overview and Alt-Tab. In that
we'd also keep shaded windows mapped, and could remove all unmap logic,
but we'd need a more complex method of showing the shaded titlebar, such
as using a different actor.

At the same time, simplify the compositor interface by removing
meta_compositor_window_[un]mapped API, and instead adding/removing the
window on-demand.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
compositor: Delay meta_compositor_add_window until the first show

In order for the compositor to properly determine whether a client
is an X11 client or not, we need to wait until XWayland calls
set_window_id to mark the surface as an XWayland client. To prevent
the compositor from getting tripped up over this, make sure that
the window has been fully initialized by the time we call
meta_compositor_add_window.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
Move position-changed / size-changed signals to the MetaWindow

They fit more appropriately over here...

https://bugzilla.gnome.org/show_bug.cgi?id=720631
window-actor: Split into two subclasses of MetaSurfaceActor

The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:

  * X11 compositor. In this case, we're a traditional X11 compositor,
    not a Wayland compositor. We use XCompositeNameWindowPixmap to get
    the backing pixmap for the window, and deal with the COMPOSITE
    extension messiness.

    In this case, meta_is_wayland_compositor() is FALSE.

  * Wayland clients. In this case, we're a Wayland compositor managing
    Wayland surfaces. The rendering for this is fairly straightforward,
    as Cogl handles most of the complexity with EGL and SHM buffers...
    Wayland clients give us the input and opaque regions through
    wl_surface.

    In this case, meta_is_wayland_compositor() is TRUE and
    priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.

  * XWayland clients. In this case, we're a Wayland compositor, like
    above, and XWayland hands us Wayland surfaces. XWayland handles
    the COMPOSITE extension messiness for us, and hands us a buffer
    like any other Wayland client. We have to fetch the input and
    opaque regions from the X11 window ourselves.

    In this case, meta_is_wayland_compositor() is TRUE and
    priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.

We now split the rendering logic into two subclasses, which are:

  * MetaSurfaceActorX11, which handles the X11 compositor case, in that
    it uses XCompositeNameWindowPixmap to get the backing pixmap, and
    deal with all the COMPOSITE extension messiness.

  * MetaSurfaceActorWayland, which handles the Wayland compositor case
    for both native Wayland clients and XWayland clients. XWayland handles
    COMPOSITE for us, and handles pushing a surface over through the
    xf86-video-wayland DDX.

Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.

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