Add a virtio_write_clipboard() function

Make it easier later to send customized clipboard message
Add a warning for unhandled case
Add VD_AGENT_CAP_MAX_CLIPBOARD support

Do not send clipboard data bigger than last received
VDAgentMaxClipboard.

There is no need to further limit at the session agent, since it is
already OOM safe, and since marhsalling/sending is local, that shouldn't
make any stability or speed difference that deserves the added
complexity.
randr: Make resolution changing more robust

When running a guest using a KMS QXL driver on a RHEL6 hypervisor,
spice_vdagent would crash on resolution changes with:
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  21 (RRSetCrtcConfig)
  Value in failed request:  0x0
  Serial number of failed request:  75
  Current serial number in output stream:  75

(if using a newer QEMU, this will not crash as the resolution codepath is
totally different, see red_dispatcher_use_client_monitors_config() in
spice-server, when using the UMS QXL driver, the crash will not happen
because of
http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=907d0ff0
).

This crash happens in vdagent_x11_set_monitor_config() because the X server
rejects the request because we are trying to set a CRTC to a size which is
bigger than the current screen (using 'screen' and 'CRTC' as in the RandR
spec at http://www.x.org/releases/X11R7.5/doc/randrproto/randrproto.txt ).

If we resize the screen before changing the CRTCs resolution, then this
error will no longer happen. However, if we first call XRRSetScreenSize()
and then XRRSetCrtcConfig(), the call to XRRSetScreeSize() will fail when
we try to make the screen smaller as there will be active CRTCs which would
be bigger than the screen.

In order to solve these issues, we follow the same process as what mutter
does in meta_monitor_manager_xrandr_apply_configuration()
https://git.gnome.org/browse/mutter/tree/src/core/monitor-xrandr.c#n689:

1. we disable the CRTCs which are off and the ones which are bigger than the
   size we want to set the screen to.
2. we resize the screen with a call to XRRSetScreenSize().
3. we set each CRTCs to their new resolution.
Don't abort if XRRSetCrtcConfig fails

In certain configurations (Fedora 20 or RHEL7 guests on a RHEL6 host), this call
fails, which cause the vdagent to abort. This patch prevents the crash, though
arbitrary resizing is obviously still non-functional in this situation.
randr: set physical screen size to keep a constant 96 dpi

Some applications compute DPI based on physcial screen size.  Currently,
the width is reported to be 270mm, regardless of the resolution.  This
patch instead compute a physical screen size to have a constant DPI of
96. Of course, there are possible improvements to this approach (see
fixme), however, since that code is no longer executed with DRM driver,
I don't think we should invest more effort here (I guess DRM driver
relies on xrandr / gnome-settings-daemon to do the right thing, so
physical screen is updated)

https://bugzilla.redhat.com/show_bug.cgi?id=1066094
Fix gdm autostart path

gdm 3.1.90 (June 2011) changed the path where .desktop files which should
be autostarted with gdm needs to be located.
This used to be $(datadir)/gdm/autostart/LoginWindow and is now
$(datadir)/gdm/greeter/autostart.
This means that when running gdm in a VM in a recent distribution,
arbitrary resizing the VM window will not cause the resolution to be
adjusted. This used to be working in eg RHEL6.

This patch installs the .desktop file to both paths in order to work both
with older and newer gdms.