Switch from using Core events to using X Input events for pointer
devices in order to differentiate between mouse events and touch events.

Because FLTK doesn't understand X Input 2, we intercept these events and
translate them to core events where possible.

Most window managers won't like this, and it tends to provoke bugs in
FLTK, so let's avoid it. It's probably not what the user wants anyway.

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

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.

We're usually white listed, but let's be a good citizen and formally
request the keyboard grab ability from the compositor.

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

Avoid direct access to the screen dimensions and layout so that we
can make sure it stays sane. This also makes sure the layout is
properly updated when we only get the screen dimensions from the
server.

We should be looking at the physical monitor layout, not the current
RFB layout. The latter might not be in sync with the local monitors.

Remnants from an earlier version of the code.

Makes sure it is readable in a multi screen configuration, as otherwise
it might end up crossing multiple screens.

It can get a bit intrusive for experienced users, so try to reduce
the impact of it.

Grabbing (and ungrabbing) the keyboard generates fake focus events
with modern versions of Xorg. This causes an infinite loop since we
update the grab status on focus events.

Work around this by ignoring these fake events.

It is no longer a workaround but rather intended behaviour.

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.

The VNC servers aren't great at getting full frames with each update,
so avoid calling it "frames per second" in the statistics as that
can be misleading.

Copy paste errors/brain fart:

 - Pixels do not need a factor 8 for any conversion

 - Multiplying bytes by 8 gives bits, so lower case 'b', and bits
   use SI prefixes, not IEC

Similar to 841e9f32d5 but for the
pointer. Fixes a problem where the desktop environment is unresponsive
(to the mouse) after fullscreen exit; Fixes #579.

We might be calling this outside a normal FLTK event, so we cannot
trust fl_event_time to have a sane value.

We don't need the grab any more if the pointer cannot click on our
window. This makes it possible to shift focus to another application
when we aren't covering all monitors.

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

Have a window that is sized to the remote screen.  Now shrink the window
vertically, making it shorter than the remote screen in one axis. The
vertical scrollbar appears. However, the horizontal scrollbar does not
appear, despite the rightmost ~24 pixels (Fl::scrollbar_size()) being
hidden by the vertical scroll bar.

Fix that.

For clarity, move the fullscreen checks into a separate `if` statement,
rather than keeping the size and fullscreen checks together.

I think the comment does a decent job of explaining and justifying the
check's logic, but if you require further convincing, perhaps this
alternate explanation will help:

  The check for the X-axis is

      if ((w() - (h() < viewport->h() ? Fl::scrollbar_size() : 0) < viewport->w())

  To be a bit more verbose and repetitive, we can split that ternary in to
  two separate checks, and add some comments:

      if (
             (w() -  < viewport->w()) // X needs a scrollbar
          ||
             ( (w() - Fl::scrollbar_size() < viewport->w()) && (h() < viewport->h()) )
             //( X doesn't need a scrollbar unless Y does ) && (  Y does need one  ) )
         )

  Within the "Y does need one" check, we don't need to worry about the
  case where `h() - Fl::scrollbar_size() < viewport-h()` is true,
  because if both axes are saying "I don't need a scrollbar unless
  you do", then neither needs one.

Some backends don't like empty draw operations, so have an early check.

Adds an optional graph to the viewer to display current frame rate,
pixel rate and network bandwidth. Makes it easier to debug and test
performance related issues.

Incoming width specifies wrapping width, and we do not want any wrapping.

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.

Stop fighting with the FLTK scroll widget and handle layout ourselves.
This opens up the possibility of doing more complex drawing as well.

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.

It doesn't really make sense anymore given that settings might come
from the GUI or configuration and not only the command line.

This workaround is no longer effective with the new system handler
method of handling keyboard events. The bug has also been fixed
in upstream FLTK, further making it pointless.

This means that we can remove a lot of conditionals and fallback code.

The local window manager might give us a window of a different size
than the one we request. Make sure that the remote resize setting
gets respected even in this case.

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.

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

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.

Reduces header dependencies.