screen: Tweak workspace initialization (again)

Commit 8100cefd4c34a fixed a crash during workspace initialization by
tweaking the startup sequence; as a result, the plugin (like gnome-shell)
is now started before workspaces are fully initialized, which breaks
some reasonable assumptions (like always having an active workspace).
This is particularly problematic considering that the code making those
assumptions is not necessarily our own (extensions!), so return to
fully initialize workspaces before the compositor again.
At the same time, make sure to only call meta_workspace_activate()
once during initialization to avoid reintroducing the crash.

https://bugzilla.gnome.org/show_bug.cgi?id=732695
wayland: Move DataOffer / DataSource into data-device internals
wayland: Add a wrapper for set_input_focus

So we're not poking into seat internals.
wayland: Fix include ordering

This puts it in the same order as the types in the struct.
wayland: Remove seat->display

It's unused.
data-device: Start a cleanup
data-device: Don't look up the same client twice in two different ways
data-device: Use a better variable name than "resource"
data-device: Put the DataDevice implementation in its own struct
wayland: Remove a few unused fields from MetaWaylandCompositor
wayland: Remove an unused field from MetaWaylandFrameCallback
Don't add in our old input event mask when we select input events

This causes a round-trip to the server, and just isn't necessary, since
we're always in charge of our event mask.
frame: Only XSync when we're on the X11 compositor backend

The only case we have is the case where the two X11 connections are the
same. When on Wayland, the XSync is costly and expensive, and we should
minimize it.
screen: Fetch the COW window up-front

XGetCompositeOverlayWindow is a round trip to the X server. We shouldn't
be doing it on every MapWindow.
window-props: Use the standard property type system for WM_WINDOW_ROLE

There seems to be no reason we can't just use this.
window-props: Use the standard property type system for _NET_WM_WINDOW_TYPE
window-props: Fix assert testing

I have *no* idea how this even compiled in the first place. What the hell?
window-props: Don't load WM_STATE

Since we don't do anything with it.
window-props: Use a flags-based approach for our prop hooks

This allows us to extend the table better with newer flags.
window-props: Fizzle out PropertyNotifies that happen after initial map

Properties like _NET_WM_DESKTOP and _NET_WM_STATE are supposed to be
ignored after the initial map of the window, so ignore any
PropertyNotifies for these.