Have more guards against mis-use of surfaceless QWaylandSurfaceItems

Change-Id: Ib380076e46b7d70442381be3328a240d81c77110
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Delete data device manager while display is still alive.

Change-Id: I7691e06d75866034c93020ebdfb45421275fcf9d
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
Avoid crashing race condition.

Change-Id: I940bcbc509a689804a02f71af45f5efc19bccf9f
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
MER: Add packaging.
MER: cmake unscrew

Change-Id: I92d57630933dacaed1e60805105adc0aae5aa2a2
MER: HACK: Don't use QWaylandInputContext

We want to use Maliit.

Change-Id: I10d50229a131feeb3c10d061aac5d805bb936849
Introduce QWaylandSurfaceInterface

Wayland is designed to be easily extensible with new protocol,
unfortunately it currently isn't possible with QtCompositor.
A QtWayland compositor has two ends: the Wayland end and the shell/wm
end, which may be implemented in QML. These two ends communicate mainly
through the QWaylandSurface and the QWaylandSurfaceView classes, but the
Wayland end is currently unable to hook into custom protocol extensions.
This is the purpose of the new QWaylandSurfaceInterface class, and of
QWaylandSurfaceOp and its subclasses: based on the QEvent model,
QWaylandSurfaceOp has only a type member, and its type specific subclasses
have additional data if needed. A custom protocol implementation, such as
xdg_surface or my_fancy_surface, will use a QWaylandSurfaceInterface subclass
which will call its specific protocol functions when it gets the relative
operation requests from the parent surface.
The QWaylandShellSurface class is now redundant so it is removed.
Add more API to change QWaylandSurface properties

The previous patch allows for QWaylandSurface to call into custom
protocol implementations, but the other way around is needed too.
Instead of adding many public setters to QWaylandSurface this
makes QWaylandSurfaceInterface the way to set them, through
protected functions. This avoids calling the setters from other code
paths, which would bring the server and client states of the same
surface out of sync.
Add a way to have out of source shell integrations

Some platforms (especially non-desktop ones) may use a custom
Wayland shell extension, more tailored to the form factor than
the generic and desktoppy wl_shell or xdg_shell. Instead of stuffing
N protocol implementations in the QPA plugin use a plugin architecture
to allow them to live out of tree.
When creating a shell surface the QT_WAYLAND_SHELL_INTEGRATION env
variable will be checked, and if it points to a valid plugin that
will be used to create the shell surface, falling back to wl_shell
or xdg_shell if no plugin is specified.