Do not link client before platform.

libplatform depends on libclient and thus linking with
platform also links with client.

However -- on linux, at least when using ld.gold (which is the default
linker on most platforms now), the order of linking static libraries
is important and cmake removes the seemingly duplicated libclient.a
that platform adds. Hence, by linking with "... client ... platform ...",
the resulting link command contains 'libclient.a ... libplatform.a',
in that order which causes an undefined reference in libplatform.a
for references to libclient.a.

By removing the mentions of 'client' when we link with platform,
the final order is swapped and things work link again.

Note that currently syngergy is not actually using libclient from
libplatform on linux (but only on OSX and windows) so that this problem
was not spotted before. However in subsequent patches I will add
this dependency for linux too and therefore need this patch.
Move members to CPlatformScreen base class. Add CPlatformScreen::enter.

Move the members m_isPrimary, m_isOnScreen, m_x, m_y, m_w, m_h
from CMSWindowsScreen, COSXScreen and CXWindowsScreen to their
base class CPlatformScreen.

Add CPlatformScreen::enter(SInt32 xAbs, SInt32 yAbs), to be called
with the absolute mouse coordinates where a new screen is being
entered.

This patch has currently no effect (except that class COSXScreen
omitted to initialize m_x, m_y, m_w and m_h, which is now fixed),
but is needed in a future commit to avoid code duplication.

A lot more stuff can be moved from the platform subclasses to
their base class, but I restricted myself to the absolutely necessary
in order to keep as much as possible the same with respect to
upstream.
Add protocol 1.6 client with msgs kMsgDMouseWarp (DMWA) and kMsgDLockScreen (DLCK)

Adds CClient::warpMouse, CClient::lockScreen, CClient::mouseWarp,
CServerProxy::mouseWarp, CServerProxy::warpMouse, CServerProxy::lockScreen,
and CBaseClientProxy::isLockedToScreen.
Removes CScreen::isLockedToScreen because that always returned false,
and removes CPrimaryClient::isLockedToScreen because that called
CScreen::isLockedToScreen.

The CServer::onMouseMoveSecondary was changed use relative mouse
coordinates when isLockedToScreen() returns true, rather than
when m_relativeMoves && isLockedToScreenServer() because m_relativeMoves
is reset to false anyway, and we're not interested in only what the
server thinks, but also what the clients think now: isLockedToScreen()
returns true when isLockedToScreenServer() is true, but also when
a client asked for a lock (see DLCK below).

The patch adds support for two new protocol messages:
DMWA : Mouse WArp
DLCK : screen LoCK

The latter only travels from client to server and requests
the server to be locked or unlocked (parameter 1 or 0 respectively).
While locked, the server sends this client only relative mouse
movements and does not detect edges.

DMWA takes two signed integers as parameter which represent the
relative offsets of the mouse pointer (the warp).
When sent from client to server, it is a request to warp the internal
coordinates that are used, after which the server sends it back
with the same values to indicate that it did just that.

When the client receives the latter, it calls CPlatformScreen::mouseWarp
which currently does nothing. Nor does the client currently send
these new messages; but they will be used in the next commit.
Automatically detect mouse warps and correct for them.

This patch voids the need to press ScrLk to play games that do mouse warping.

IT WAS NOT TESTING ON WINDOWS OR MAC. Although it should work, it is
very likely to need a bit more tweaking before it works on those
operating systems.  This patch was tested on linux.

The idea of this patch is the following:

1) The client also turns on receiving motion events.
2) Whenever the cursor is placed with absolute coordinates,
   those coordinates are stored in a stack.
3) When a motion event is received for coordinates in that
   stack then we're happy. Otherwise we assume a warp happened.
4) If a warp happened, the client switch locally to relative
   mouse coordinates (only asks the screen to do relative mouse
   movements) in order not to disturb the warp.
   In the meantime it sends the warp to the server, which
   updates its coordinates. A few milisecond later things should
   be synced again.
5) If no sync happens (because we don't receive motion notifications
   anymore) several mouse movements (from the server) long, then
   the client takes it a step further and asks the server to
   lock the screen (really switch to relative mouse movements);
   this is necessary to avoid that if the mouse is moved to
   the edge of the screen that we can't move it any further,
   despite that we want to be in relative mouse mode.
6) If a mouse button is pressed, then the client assumes
   that very likely we will not receive any motion notifications
   anymore and switches to relative mouse movements too.
   This doesn't however break file dragging, because in that
   case we do receive motion notifications, which flip the client
   back to absolute mouse mode.
7) At all times we switch back to absolute mouse mode when
   coordinates received from the server correspond with motion
   notifications that we are receiving (and unlock the screen).
   But the client also switches back to absolute mouse mode
   whenever a warp sync is received from the server (which might
   or might not lead to another warp that already happened
   in the mean time, as soon as updated mouse coordinates are
   received and a motion notification is received, that can be
   compared).