a11y: Don't use signals

Instead, call functions directly. Fixes the fact that the signals
weren't disconnected even when the accessible was destroyed.

https://bugzilla.gnome.org/show_bug.cgi?id=725733
treeview: Split out a function

This is in preparation for the next patch.
treeview: Don't popup a search dialog for keypresses that close it

That doesn't make sense.
And it causes issues, because when holding down the tab key, we
show/hide a lot of windows and cause a lot of map/unmap events that
stall the event pipeline.
Work around gcc stupidity

With -Wc++-compat, gcc warns about 'and' even in contexts where it
poses absolutely no danger.

https://bugzilla.gnome.org/show_bug.cgi?id=726136
GtkTreeView: stop ignoring crossing events from grabs

Stop ignoring various crossing events from grabs:

Enter events with type GRAB/GTK_GRAB/GTK_UNGRAB/STATE_CHANGED:
  Ignoring these events was added as a workaround for synthesized
  events not having the right coordinates (see bug 555109) but
  now they do have the right coordinates. (see bug 704456)

Leave events with types types GTK_GRAB/GTK_UNGRAB:
  Ignoring these events was added because since we were ignoring
  the enter events as above, ignoring the leave events meant we
  could lose the prelighted row in a grab-triggered leave/enter
  pair. (See bug 653676. It's also now impossible to
  reproduce the leave events that were reported in that bug as causing
  problems.)

Leave events of type GRAB.
  Ignoring these events was added without a ChangeLog entry in 2001,
  possibly to keep the prelight from flashing when activating menus.
  But ignoring these events could lead to stuck prelighting, and we don't
  do it for any other widgets.

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

The bug this patch is fixing is that currently if you have a GtkPopover in
clicking off the popover to dismiss it on a GtkTreeView (which triggers
a synthetic enter event on the GtkTreeView) will leave the GtkTreeView
in a confused state until the user moves the mouse again.
documentation: clarify gtk_icon_theme_add_builtin_icon() usage

https://bugzilla.gnome.org/show_bug.cgi?id=726135
Use GDK's current window tracking when synthesizing events in GTK+

Add gdk_device_get_last_event_window(), and use to implement the window
tracking we need for synthesizing crossing events for sensitivity changes
and gtk grabs, rather than keeping the information in qdata and updating
it based when GTK+ gets events.

https://bugzilla.gnome.org/show_bug.cgi?id=726187
Add a Since annotation to gdk_device_get_last_event_window
Update a11y test output

These harmless changes are a consequence of
66fae0330c5cdb68f50699ff2645ff0cf112911e.
xdg-shell: Update to latest state change mechanism
_gtk_widget_get_device_window: Fix for keyboard devices

Avoid a warning by returning NULL for keyboard devices, which can
never have an active pointer for a widget.
Show dialog titles

We want to present a clean, rounded top when there is nothing
else to show, but many dialogs in applications rely on showing
information in their title, so add a label and show the title
when it is not empty.
Test size constraints

This adds some min/max size hints to testimage.
Updated French translation
Updated French translation
Updated French translation
Finnish translation update by Jiri Grönroos
dialog: Avoid possible use-after-free

When the dialogue's titlebar was replaced, we were still trying to
update the label we constructed but that was now destroyed.

https://bugzilla.gnome.org/show_bug.cgi?id=726492
x11: Fallback to emulated window dragging for touch devices

Sadly, EWMH moveresize mechanism can't work with touch devices for two
reasons:

1) As a mutter implementation detail, the device is queried in order
to check whether the dragging button is still pressed. Touch devices
won't report the button 1 being pressed through pointer emulation.
2) Even bypassing that check, on X11 touch events are selected prior
to sequences being started, either through XISelectEvents or
XIGrabTouchBegin, no late registering through active grabs is allowed,
as WMs do on reaction to EWMH moveresize messages.

So for the time being, make touch devices fallback on emulated window
dragging, which at least allows for moving windows.

https://bugzilla.gnome.org/show_bug.cgi?id=709914
x11: Implement "drag to top to maximize" gesture on emulated window dragging

And the counterpart to unmaximize when dragging a maximized window, if
touch devices aren't going to use EWMH moveresize, having this one at least
makes things feel a bit less awkward.

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