Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.

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.

Makes it easier to see what is overloaded and what isn't.

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

Some input sources are still using input methods even though they
claim to be "ASCII" input. This causes our input handling to fail
since we need to query the layout to handle dead keys.

Fortunately there is another API to get the raw, underlying input
source that the input method uses. So let's use that and be sure
that we're always getting something we can use.

The parameter files are used to make sure changes in the UI are
persistent. Storing anything else results in behaviours that the
user has no easy way of changing.

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 need to make sure it is null terminated on truncation. We also
need to avoid giving a too large size argument or modern gcc will
complain.

It's not common knowledge these days how X geometry is specified, and
even the man page X(7) is missing on many systems now.

FLTK has some options (that we've also documented in the man page)
that should be mentioned in the --help output.

We can use a dummy value here as we set up the buffer and stride
further down in the constructor.

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.

Logging revealed that a few empty damage regions are emitted on startup. Those don't need to be rendered to the Surface pixmap.

The Pixmap is filled in as updates from the server arrive. Before the first full update, it would contain undefined contents, which would be rendered onto the ViewPort.
Clearing the Pixmap is only done on startup and when changing the server resolution, so it's not performance critical.

These are not allowed in C++, and have been made optional in C11.
So let's just get rid of them and any issues they may cause.

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.

ServerParams should contain the server state and not information about
client settings or capabilities. Move those things up a level to the
CConnection object.

No need to have one setting for each extension. All the client code
needs to indicate is if it supports resize. The common code can then
map this to relevant extensions.

These were either completely unused, or always true.

It's a generic client thing, so abstract it in to the common library.
Makes it easier to integrate with other common code.

Avoid using the callbacks used for runtime changes for the initial
setup. They weren't really useful anyway as you could not allocate
a framebuffer without also knowing the pixel format. So make things
more clear by letting serverInit() get the initial settings.

Add an explicit callback for subclasses to do their startup in. This
makes it easier to do proper ordering, and avoids mistakes.

This method was only really useful when continuous updates was active,
so let's rely on a single extension rather than two.

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.

Our XRender code assumes a certain pixel layout which was not
guaranteed on big endian systems. The previous workaround only worked
for some cases, so fix this properly now.

Our main web site now supports https, so update all references.

We've had support for unix sockets for a while now. Make sure this
is reflected in the -help output and the man page.

Also make some minor tweaks to the section to get everything in
sync with reality.

The compiler isn't smart enough to figure all of these out, so
restructure things a bit to avoid warnings.

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.

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.

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

We had partial coverage for vncviewer/ already, but fix up the last
pieces.

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.