QEMU instead of having libmks handling that when resizing the widget
This also would allow having an option for auto-scaling that would
scale the texture to fit the widget size
Otherwise the VM would have no idea about the size of the target widget.
To do so, we introduce a ScreenResizer object that remembers the previous
screen attributes as well the next attributes to configure.
Taking care of scheduling resize operations and avoids submitting
the same attributes twice.
This allows setting a customizable trigger which may be used to ungrab
the display. Currently, the default is ctrl+alt+g and the only thing that
will be released is the shortcut inhibition.
This will allow us to receive input like Super for the activities overview
while the widget is active.
We still need a way to release the grab, but that will come soon.
This is a child widget to the MksDisplay which contains just the paintable
region of the remote screen. Doing so allows us to avoid having to handle
crossing events carefully for things like cursors.
Instead, now the MksDisplay calculates the area for the picture and
allocates it there. The MksDisplayPicture will always snapshot the
paintable using the full area it has been allocated.
Event processing can also largely move into the Picture widget which
simplifies bounds checking.
We may need to tweak this for relative mouse positions if we find we dont
get reliable information from the peer. But this is a start, which I see
we get back from Qemu at least when we're in -enable-kvm mode.
Now that we are doing our own paintable management, we can more easily
transition to doing our own event management with the Legacy event
controller (which, despite the name, really just allows us to get more
direct GdkEvent for processing).
Additionally, this adds support for scroll events to the guest.
We want a bit more control over things than we can get with GtkPicture so
do the snapshot/measure internally. This allows us to know where the
picture is to be allocated so that we can translate pointer events to the
location within the console.
We need to handle a mouse that is not absolute positioned (the default it
seems) and this does that (crudely for the moment until we have some sort
of grab management).
Additionally, click events are propagated to the Qemu instance as well.
We don't need to do this manually now that we have GtkPicture working
correctly with content-fit. We still want to maintain our own widget to
manage things like grabs and all that though.
