So far we have used the agent to notify the guest of a request to change
the monitors configurations (heads) on the qxl device. This patch introduces
a new interrupt and new fields in the qxl rom to notify the guest about
a new request, similarly to how physical hardware notifies the driver.

We compute crc over the monitors configuration to avoid host-write from a
following update while guest-read corruption. The update protocol is:

qemu:
  (2) fill QXLRom::client_monitors_config
  (3) raise QXL_INTERRUPT_CLIENT_MONITORS_CONFIG

guest:
  (1) clear QXL_INTERRUPT_CLIENT_MONITORS_CONFIG bit in irq status
  (2) read QXLRom::client_monitors_config
  (3) (verify-crc)? done : goto 2

If the interrupt mask is ~0 or 0, or does not have
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG set, we also assume it doesn't support
this interrupt.

The client_present field is a byte that is set of non-zero when a
client is connected and to zero when no client is connected.

The client_capabilities[58] array contains 464 bits that indicate the
capabilities of the client. Each bit corresponds to a
SPICE_DISPLAY_CAP_* capability. In particular, if the client has
capability C, then bit (C % 8) in byte (C / 8) is set. The capability
bits only have a defined meaning when a client is connected, ie., when
client_present is non-zero. The number 58 was chosen to fill out a
cache line in QXLRom.

A new QXL_INTERRUPT_CLIENT interrupt is defined, which will be raised
whenever a client connects or disconnects.

Even though the ability to handle a8 surfaces was added at the same
time as the composite command, they are logically separate, so add a
capability bit to indicate the presence of a8 surfaces.

Add a new arbitrary keyboard scancodes message.

For now, it will be used to avoid unwanted key repeatition when there
is jitter in the network and too much time between DOWN and UP
messages, instead the client will send the press & release scancode in
a sequence from a single message.

If the server doesn't support INPUTS_CAP_KEY_SCANCODE, the client is
responsible to handle a fallback mode with the exisiting KEY_DOWN and
KEY_UP messages.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=812347

The main difference between semi-seamless and seamless migration is that
while in semi-seamless migration the state of all the channels is
being completely reset after migration is complete, in seamless migration
the essential parts of the state are restored on the server side, and
are left the same on the client side. semi-seamless migration is
equivalent to having the client disconnect from the src and connected
from scratch to the dest, with the exception, that the handshake with
the dest server occurs before the client has disconnected from the src.
In semi-seamless migration in-flight data gets lost, e.g., a file
transfer to a usb device might be disrupted.

=======================
===protocol details====
=======================

Let s1, s2, and c be the src server, dest server and client, respectively.

Semi-Seamless migration protocol
================================

pre-migration phase:
--------------------
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_BEGIN
    In response, c tries to establish a connection to s2. After the connection is
    established, it is inactive (the client doesn't attempt to read or
    write messages from/to it)
(2) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED or
           SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR

post migration phase:
---------------------
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_END or
           SPICE_MSG_MAIN_MIGRATE_CANCEL
    In case of the former, c disconnects from s1, resets all its
    channels states and switches to an active connection with s2.
(2) c->s2: SPICE_MSGC_MAIN_MIGRATE_END
    The msg signals that all the channels have been migrated successfully to s2.

Seamless migration protocol
===========================

pre-migration phase:
--------------------
In case qemu/libvirt/client do not support seamless migration,
s1 takes the semi-seamless pathway for migration. Otherwise:

(1) s1->c: SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS (*New*)
    The msg includes the version of the migration protocol
    of s1.
    In response c tries to establish a connection to s2.
(2)
    If the connection fails:
    (2.1) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR

    If s2 supports SPICE_MAIN_CAP_SEAMLESS_MIGRATE:
    (2.2) c->s2: SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS (*New*)
          The msg includes the version of the migration protocol
          of s1. The msg is used for querying s2 if seamless migration
          is possible, given the migration protocol version of s1.

      (2.2.1) s2->c: SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK (*New*)
      (2.2.2) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS (*New*) or
                     SPICE_MSGC_MAIN_MIGRATE_CONNECTED
              The latter is sent when c receives SEAMLESS_NACK, and
              indicates s1 to apply semi-seamless protocol on post
              migraion phase.

    If s2 does not support SPICE_MAIN_CAP_SEMI_SEAMLESS_MIGRATE:
    (2.3) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED
          (see 2.2.2)

post migration phase:
---------------------
While the pre migration phase was conducted by the main channel, this
phase's protocol occurs in all the migrated channels.

(1) s1->c: SPICE_MSG_MIGRATE
    The msg marks the client that the connection is paused from s1 side, and
    next to this msg, the only possible msg s1 can send is
    SPICE_MSG_MIGRATE_DATA

    msg optional flags:
    (a) MIGRATE_FLUSH_MARK
        This flag is required for finalizing the channel connection
        without losing any in-flight data.
        This flag indicates that s1 expects SPICE_MSGC_MIGRATE_FLUSH_MARK,
        for signaling that c will pause the connection and not send any more messages
        to s1.
    (b) MIGRATE_DATA
        The flag indicates that c should receive from s1
        SPICE_MSG_MIGRATE_DATA
(2) c->s1: SPICE_MSGC_MIGRATE_FLUSH_MARK (if required)
    c pushes the msg to the head of its output msg queue,
    and sends it before all its other pending msgs - they will be sent to s2
    later.
(3) s1->c: SPICE_MSG_MIGRATE_DATA (if required)
    The msg contains all the data that the server requires for restoring
    the channel's state on s2 side correctly.
(4) c disconnects the channel from s1 and switches to an active connection
    with s2.
(4) c->s2: SPICE_MSGC_MIGRATE_DATA

Similarly to SPICE_MSG_AGENT_CONNECTED, the msg notifies the main
channel about attaching an agent. In addition the msg also contains the
number of tokens allocated to the client.

This new command is intended to be used for implementing the Composite
request from the Render X extension. See

   http://www.x.org/releases/current/doc/renderproto/renderproto.txt

for a description of the Render extension.

Composite has three fields: src, mask and destination, of which mask
is optional (can be NULL). There are also two pointers to
transformations, one for each of src and mask.

The command also has 32 bits of flags which indicates

- which compositing operator to use
- which filters to apply when sampling source and mask
- which repeat mode to apply when sampling source and mask
- whether the mask should be considered to have 'component alpha'
- whether the alpha channel of any of the images should be ignored.

The last one of these features is necessary because in the X protocol
an offscreen surface is simply a collection of bits with no visual
interpretation. In order for Render to use these bits, a wrapper
object is used that contains the pixel format. Since one offscreen
surface can be wrapped by multple objects, there is not a one-to-one
correspondence between pixel formats and surfaces.

In SPICE surfaces do have an associated pixel format, which means the
above feature of Render cannot be supported without adding a similar
concept to the wrapper object to the SPICE protocol. However, the most
common use for having multiple wrappers for one offscreen surface is
to interpret an alpha surface as not having an alpha channel or vice
versa.

This format corresponds to a sequence of bytes, each of which
represents an alpha value.

Adds on device:

RAM
 Header
  monitors_config - pointer

 QXLMonitorsConfig
  count == n
  max_allowed = N >= 0
  QXLHead 1
  ...
  QXLHead n
   id, surface_id, x, y, width, height, flags

IO:
 QXL_IO_MONITORS_CONFIG
  server flushes command ring, then calls server callback for changing monitors config.

New revision to let the driver know about the new io:
 QXL_REVISION_STABLE_V12=0x04,

Adds server/client capability:
 SPICE_DISPLAY_CAP_MONITORS_CONFIG

Server message will be added in spice-server and spice-common.

Version is bumped to 0.12.0 to indicate new IO and structs