We've traditionally left GTK+ to handle the input side of things,
letting GDK only manage the windowing-specific messaging. This
way of splitting responsibilities is not compatible however with
some backends, we must fold then input management at the DnD stage
into GDK (and backends) domain.

The gdk_drag_context_manage_dnd() call is meant to be the entry
point for this mode of operation, if the drag and drop operation
becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
grabs, nor manage input events itself.

As a consequence of this, different aspects now belong to the
backend GdkDragContext implementation:
- Because the caller doesn't see keyboard events anymore,
  keyboard navigation must be managed in GDK, so is the decision
  of the current action based on modifiers/button pressed.
- Because the caller won't see input events in general, the lifetime
  of the drag and drop operation is now communicated through the
  ::drop-performed, ::dnd-finished and ::cancel events
- Because the caller doesn't participate anymore on the action
  being chosen, the pointer cursor must be set by the backend.
  The caller is rather notified of the final action through the
  ::action signal.

The caller is still responsible of dealing with the corresponding
GdkSelection, ensuring its ownership and communicating the supported
mimetypes.