frames: Hackily adapt to GTK+ drawing changes

mutter is quite bad at using GTK+ correctly, relying on dumb things
like the single-buffering stuff. Hack up a temporary fix for the
newer GTK+ rendering changes.
frames: Don't bother painting the background

GDK (and also GTK+!) do this for us already.
frames: Simplify the clip region calculation

Since GTK+ already clips to the extended region for us, there's no need
to combine the two. This does lose the fast-path, but I don't actually
expect this to fire, as when we're composited, we really won't ever get
partial exposes.
Revert "window: Move placement code from the constraints path"

Window state like maximization and minimization should be preserved
over restarts - in a patch review, this would qualify as "needs-work",
so revert the cleanup until the issues are fixed.

This reverts commit dc6decefb5cbd14d5ab059a59952fd96e86dc763.
window: Don't make windows on non-primaries sticky on restart

When workspaces-only-on-primary is set, a window can be on all
workspaces either because it is on a non-primary workspace, or
because it was explicitly made sticky. Only the latter is reflected
in _NET_WM_STATE, but both will result in a "magic" _NET_WM_DESKTOP,
which we (and probably other WMs) use to set the initial sticky state.
So to avoid confusing other WMs (or ourselves), make sure to only
have _NET_WM_STATE_STICKY reflected in _NET_WM_DESKTOP when unmanaging.
window: Keep track of preferred output

Remember the last monitor a window was moved to by user action and
try to move it back on monitor changes; this should match user
expectations much better when a monitor is unplugged temporarily.

https://bugzilla.gnome.org/show_bug.cgi?id=731760
window: Add user_op parameter to update_monitor()

When workspaces-only-on-primary is set and a window is moved back to the
primary, we also move it to the active workspace to avoid the confusion
of a visible window suddenly disappearing when crossing the monitor border.
However when the window is not actually moved by the user, preserving the
workspace makes more sense - we already do this in some cases (e.g. when
moving between primary monitors), but miss others (unplugging the previous
monitor); just add an explicit user_op parameter as used elsewhere to cover
all exceptions.

https://bugzilla.gnome.org/show_bug.cgi?id=731760
Bump version to 3.13.3

Update NEWS.
Updated Russian translation
window: Add a property for on_all_workspaces

Some plugins and extensions want to be able to know when the sticky
field of a window changes, so add a property for it and allow them
to connect to the notify::on-all-workspaces signal.
window: Use g_object_class_install_properties
window: Use g_object_notify_by_pspec
wayland-pointer: fix condition for grabbing

It returns FALSE when button_count is not 0. But grabbing for
move/resize is activated by clicking the button, so this condition
disallows the wayland clients to be moved/resized.

https://bugzilla.gnome.org/show_bug.cgi?id=731237
wayland window: update buffer_rect when moving

Update both - rect and buffer_rect positions when moving wayland window

https://bugzilla.gnome.org/show_bug.cgi?id=731237
build: link against libinput explicitly

We use its symbol, we should link against it - or strict linkers
like gold complain.
main: kill custom log handler

It just gets in the way of gnome-shell's log handler (which
includes gjs backtraces optionally), it requires people to understand
what 8 or 16 mean as log levels, and it loses the log domain.
window: Set custom frame extents to 0 if we don't have any

This is just a quick code cleanup.
window-wayland: Correct the buffer rect for frame extents
Add ::first-frame signal to MetaWindowActor

This signal is emitted the first time a frame of contents of the
window is completed by the application and has been drawn on the
screen. This is meant to be used for performance measurement of
application startup.

https://bugzilla.gnome.org/show_bug.cgi?id=732343
meta_accelerator_parse(): handle keysyms without the XF86 prefix

The GDK and hence GNOME standard is that keys that begin with XF86 according to
libxkbcommon not prefixed with XF86, though gdk_keyval_from_name() strips XF86
if provided. If libxkbcommon doesn't recognize the accelerator name without
XF86, try again adding XF86 to the start.

This restores compatibility with gnome-settings-daemon, schemas, and existing
user configuration.

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