This change adds support for the VMware Mouse Position
pseudo-encoding[1], which is used to notify VNC clients when X11 clients
call `XWarpPointer()`[2]. This function is called by SDL (and other
similar libraries)  when they detect that the server does not support
native relative motion, like some RFB clients.

With this, RFB clients can choose to adjust the local cursor position
under certain circumstances to match what the server has set. For
instance, if pointer lock has been enabled on the client's machine and
the cursor is not being drawn locally, the local position of the cursor
is irrelevant, so the RFB client can use what the server sends as the
canonical absolute position of the cursor. This ultimately enables the
possibility of games (especially FPS games) to behave how users expect
(if the clients implement the corresponding change).

Part of: #619

1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding
2: https://tronche.com/gui/x/xlib/input/XWarpPointer.html
3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804

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.

This makes VNCServer a sufficiently complete interface that callers
don't need to know about the specific implementation (VNCServerST
currently). And assuming that all servers will use sockets is not
that outrageous.

This makes it generally useful and other code doesn't have to
know of the specific sub-class.

Avoid having VNCSConnectionST poking around in VNCServerST's internals
and instead access things via safer methods.

Make things simpler by making this a part of the SDesktop interface
that always needs to be implemented.

Based on QEMU's behaviour.

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

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.

framebuffer switch, but before we've been given the pointer to the new
framebuffer.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4839 3789f03b-4d11-0410-bbf8-ca57d06f2519

well-behaved manner.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4784 3789f03b-4d11-0410-bbf8-ca57d06f2519

and the data flow is now more strictly aimed towards this connection class.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4771 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4039 3789f03b-4d11-0410-bbf8-ca57d06f2519

It has some warts, but should be feature complete. Most of the magic happens
in the desktop class though.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3713 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2331 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/branches/merge-with-vnc-4.1.1@522 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2 3789f03b-4d11-0410-bbf8-ca57d06f2519