X11: Support keyboard-initiated move and resize operations

The EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.
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
GtkMenuTracker: tweak separator logic

Ignacio Casal Quinteiro reported a problem whereby an empty section at
the start of a menu has a separator placed after it.  This was caused by
the implementation of the logic that separators should be inserted at
the top of all non-empty sections that are not the first section.  This
logic is obviously incorrect in the case that the first section is empty
(in which case we would not expect to see a separator at the top of the
second section).

Change the logic so that we only insert separators when we see a
non-zero number of actual items in the menu before us.

https://bugzilla.gnome.org/show_bug.cgi?id=721119
W32: correctly guess max window size from the size of the workarea of the screen it's on

Get monitor on which the most of the window is located (nearest monitor if
window is not on screen), get its work area (area not occupied by taskbar or
any other bars) and use that for maxsize.

Previous default of 30000 meant that windows maximized onto full screen,
even covering the area where taskbar is.

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