Hacky attempt to try to figure out the actual key pressed when
FLTK is giving us control codes.

Remove the FLTK simple keyboard system and reorganise things in
preparation for a more direct approach.

It makes things more self contained (although you still need to
download FLTK itself), avoids the confusion of STR:s in varying
states, and allows us to refer to patches that aren't available
on an STR.

We actually require FLTK 1.3.2 as we reference FL_SOCKET.

Makes it easier to debug it by having convenient access to the
log output.

This is how the X11 API does things, so it's clearer if we use
the same principle.

Static to avoid namespace polution, and const so that it can be
shared among instances.

The input string might contain formatting marks, so make sure those
are ignored.

There is nothing using these classes anymore, so remove the clutter.

This allows us to apply a lot more server logic
independently of which encoder is in use.

Most of this class are things moved over from the
Tight encoder.

This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.

Like we do for everything else. This also gets rid
of the callback, which is a bit out of place
compared to everything else.

Add a magical cursor framebuffer class for handling when you
want to render the cursor on the server side. Keeps the cursor
specific magic in one contained place.

The core can decide to close an input device (e.g. during a
server reset). Make sure we respect this by forgetting about
the device and recreating it again later.

We don't need this anymore as we now only have a single
InputDevice object and can easily refer to it directly.

Xorg input devices are global so it doesn't make sense that we
have one InputDevice object per XserverDesktop.

This makes InputDevice cleaner and just a glue layer for Xorg
input devices.

fc23895 blocked out a bit too much code when trying to make
libvnc handle server resets. Even though configuration should
only be handled once, the underlying VNC extension needs to
be reinitilised as the X core has removed all extensions on
reset.

Allows you to modify the buffer with data in a
different pixel format.

Handles the common cases when the target or source are in
the preferred 888 format.

If one of the buffers is not 888, then it must also be properly
aligned (which is commonly the case). Performance is now in many
cases on par with PixelTransformer.

This is a lot easier and cheaper than having to set up a complete
PixelTransformer object.

You have to loop many times when converting e.g. 2 bits to 8,
so have a couple of lookup tables to speed things up. We still
use bit replication to get from 8 bits to 16 bits though.

Allows pixel buffers that do damage tracking to get
proper information.

Clearly separates the read API from the write API
and also from actual implementation.

It was confusing and not properly used everywhere.
Callers should use the stride they get when they get
the buffer pointer.

Keep things simple instead and allows us to remove the extra setPF()
methods.

This allows us to gracefully fall back to the FLTK code in case the
platform specific code cannot be used.

The connection object is a much more appropriate object for the
decoders and encoders to keep track of. Besides the streams, it also
contains state like connection parameters.

This keeps the reader and writer objects clean and simple protocol
decoders/encoders.

Gets rid of a loooot of code and complexity.

Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.

Keep the generic stream classes clean and general.