frame: Delay updating the background until the frame is ready

To determine the correct background style, the UI needs to access
some frame properties via meta_core_get(); this call will bail out
early if window->frame is unset, so delay the call until the
association is made.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
window: Parse _GTK_THEME_VARIANT property

Since version 3.0, GTK+ has support for style variants. At the moment,
themes may provide a dark variant, which can be requested by
applications via GtkSettings. The requested variant is exported to
X11 via the _GTK_THEME_VARIANT property - support this property, in
order to pick up the correct style variant in the future.

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

NOTE: Patch is adapted for metacity.
core: Allow retrieving the theme variant via core_get()

To associate frames with the correct style variant, the UI will
need access to the window's theme variant property.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
ui: Add meta_ui_update_frame_style()

This method allows forcing a style update of a particular frame
from the core, so that it can pick up style variants.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
core: Update frame style when _GTK_THEME_VARIANT changes

When the _GTK_THEME_VARIANT property changes, rather than just
updating the window's theme_variant property, update its frame
style as well, so that the window decoration reflects the requested
variant. As the initial properties of a window may be read before
its frame is created, there will be cases where the change is not
picked up initially.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
ui-frames: Delay attaching the style to new frames

Like the setting of new frames' background is delayed until the
frame is associated with its window, delay attaching the initial
style, so that the correct style variant is picked.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
ui-frame: Add support for style variants

Rather than sharing a single style context between all frames, use
a default style and one style per encountered variant. The value of
the _GTK_THEME_VARIANT property should determine which style is
attached to a particular frame, though for the time being the default
style is used for every frame, as the window property cannot be
accessed at the time the style is attached. This will be fixed in
a later commit.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
fix a crash-on-exit

meta_frames_destroy() was not safe to be called multiple times, which
was causing a crash on exit due to something else changing somewhere
that makes it get called multiple times.

https://bugzilla.gnome.org/show_bug.cgi?id=654489
frames: Explicitly initialize style contexts

We were relying on GTK+ emitting GtkWidget::style-updated during
widget initialization to create the GtkStyleContexts used for
window decorations. A recent GTK+ update broke this assumption,
so do the necessary initialization ourselves.

https://bugzilla.gnome.org/show_bug.cgi?id=671796
frames: Bump priority of style providers

Since GTK+ commit b1ad5c8abc2c, GtkSetting's CSS provider uses a
priority of GTK_STYLE_PROVIDER_PRIORITY_SETTINGS, which means it
will overwrite the ones we create ourselves.
Bump the priority to fix dark window decorations.

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