We have a timer after Ctrl is pressed in order to see if an Alt will
come right after. Ctrl + Alt is what windows sends for AltGr.
If a key other than Alt was pressed we knew that we could cancel this
timer, this commit extends that to mouse events too.

Since this detection breaks the true order of events we want to make
a decision as fast as possible.

Not every mouse has three buttons e.g. laptops. Some OS might not
have support for middle mouse button emulation.

This commit adds emulation for middle mouse button when pressing both
left and right mouse button simultaneously.

This was not necessary since you could use ESC key or simply just
clicking outside of the context menu to close the menu.

If the server doesn't support local cursors and want to render them
itself then we need to make sure the local cursor is invisible.

This also makes sure we always have some cursor allocated, so we can
remove the checks in some places.

In prepartion for better clipboard extensions that can send Unicode
data between the client and server.

Change the internal clipboard API to use a request based model in
order to be prepared for more advanced clipboard transfers.

We convert between UTF-8 and ISO 8859-1 (latin 1) in several places
so create some common routines for this.

We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.

This is required by the protocol so we should make sure it is
enforced. We are tolerant of clients that violate this though and
convert incoming clipboard data.

It is already hidden in the UI, so make sure it also is gone as a
command line parameter. This follows the behaviour of the similar
sendPrimary parameter.

We always sync when we get focus, so this code path is really only
for when the server announces LED state support after we already
have focus.

Make sure we only handle this specific scenario as otherwise we
could end up syncing twice, which just toggles things back and forth
and ends up syncing incorrectly.

We need to test this always in order to catch Ctrl+AltGr, and to
handle release of the key properly. Hopefully there isn't any other
case where VK_MENU is sent without a scan code.

We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.

For KDE we can sometimes get a bunch of stray FL_LEAVE events before
gaining focus. Sending their included button information gets things
in the incorrect order with regard to other synchronisation we do on
focus. So just ignore buttons as the only information we want out of
the leave information is a position update.

We put the try/catch as close as possible to the writes in all
other case, so make sure this code also follows that pattern.

Setting Ctrl or Alt key on menu only sends the key press, and the
state is lost when focus is lost and recovered.
This checks the menu variable and sends the keys again if needed.

We should start by getting the remote end in sync with the actual
keyboard state. This would work randomly before depending on if we
got the first LED state message before or after we got focus.

The handler is for incoming data and we should not be abusing that
class for the writer class. Do proper write prototypes for the
relevant functions.

We don't want to surprise the user with unexpected clipboard changes
when vncviewer is in the background, and it is both wasteful and
possibly insecure to inform the server of every clipboard update
when the user isn't interacting with it.

Apply workaround for FLTK's bad focus handling so that we can let
Viewport handle LED synchronisation without help from DesktopWindow.

That way both incoming and outgoing clipboard are both in the same
place, making things clearer.

Improve AltGr detection even further on Windows so we can detect the
case when Ctrl and AltGr are pressed together.

Try to properly detect the fake CtrlL+AltR sequence Windows sends
when pressing AltGr. This allows us to send more accurate key
events over to the server.

We've fixed the issue more properly in the server now, so remove the
workaround we had in the client.

The shift buttons are a bit buggy on Windows unfortunately, but we
can do slightly better than we're doing today.

Windows mostly follows the AT set 1 scan codes that we want, but
there are a few exceptions.

Make sure it can map between the key codes of the local system
in to the key codes used by the protocol.

This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.

The state might have changed when we didn't have focus. Get
everything back in sync once we're back in control.

This will allow us to use better formats that preserve the entire
alpha channel.

Some platforms draw directly to the screen, which means that updates
will flicker if we draw multiple layers. Prevent this by first
composing the update on a hidden surface.

This will allow us to render more things than just the framebuffer.

Primary selection is inherently a X11 concept so there is no point
showing the settings related to it on other platforms.

Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.

Makes it easier to see which hot-keys might conflict with each
other, and allow some variation in translation in the future.

Normally we only display screen changes once we have the updates for
the entire screen. This may give the impression that the viewer is
hung though. So display the partial data if the update is taking to
long to arrive.

There has been some confusion if fillRect() should accept a buffer
or a pixel. This can cause misrendering if your data is not in the
native endian order. A buffer makes more sense here though, and
is what most of the callers are already assuming, so change the
API to follow that.

We don't want it automatically creating submenus when least
expected.

This reverts commit e95412569b
and commit 52a18150a7.

The copy() method unfortunately has its own problems so it was not
a good replacement.

Less risk for bugs this way.

It has less surprises in terms of magical characters.