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. Theoretically, we might want to
show previews of shaded windows in the overview and Alt-Tab, so we remove
the complex unmap tracking for this later.
compositor: Remove meta_compositor_window_[un]mapped

We no longer unmap the toplevel windows during normal operation. The
toplevel state is tied to the window's lifetime.

Call meta_compositor_add_window / meta_compositor_remove_window instead...
compositor: Remove pending_input_region

Ever since the change to create the output window synchronously at startup,
there hasn't been any time where somebody could set a stage region the
output window was ready, so this was effectively dead code.
surface-actor: Move unobscured_region processing here

https://bugzilla.gnome.org/show_bug.cgi?id=720631
window-actor: Simplify the unredirected check in cull_out

https://bugzilla.gnome.org/show_bug.cgi?id=720631
compositor: Simplify the unredirected window management code

https://bugzilla.gnome.org/show_bug.cgi?id=720631
window-actor: Flip set_redirected around

I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
window-actor: Remove old unused APIs

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 CLIENT_TYPE into two subclasses of MetaSurfaceActor

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 clients. Theoretically, when the video display
protocol lands, we can implement a "Wayland" backend for this, using a
similar system.
window: Delay the showing of XWayland clients until set_window_id

Use our new "surface_mapped" field to delay the showing of XWayland clients
until we have associated together the window's XID and the Wayland surface ID.

This ensures that when we show this window to the compositor, it will properly
use the Wayland surface for rendering, rather than trying to use COMPOSITE and
crash.