Fix compilation when smartcard support is disabled

The addition of smartcard control to the controller doesn't handle
the case when smartcard support is disabled at compile time. When
this is the case, this causes compile errors.
client: keyboard - add mapping for volume keys

Add support for sending volume keys scancodes to the guest
RHBZ #552539

A good reference for mapping keymaps to scancodes can be found in
spice-gtk/gtk/keymaps.csv

Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
client X11: support volume keys when evdev is in use

Add support for sending volume keys scancodes to the guest
RHBZ #552539

Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
client/windows: fix SetClipboardViewer error handling rhbz#786554

MSDN says the following about SetClipboardViewer(): "If an error occurs or there
are no other windows in the clipboard viewer chain, the return value is NULL".
Seems like the buggy case was "no other windows in the clipboard viewer chain",
which explains the 3rd party clipboard manager workaround detailed in the bug
description.

It also seems like SetClipboardViewer() does not clear the error state on
succcess. Calling SetLastError(0) before SetClipboardViewer() seems to solves
this issue.

Since we could not reproduce the bug on our env, the customer has verified on
several of their systems that a private build resolved the issue.
build-sys: cleanup, use autoreconf
build-sys: use spice-protocol as submodule
build-sys: cleanup server/tests/Makefile.am
build-sys: fix make distcheck

- Do not refer to .c files managed by another makefile (this will fail
  make distclean)
- Do not refer to files by relative path (should use $top_srcdir for ex)
- Use LDADD for object linking instead of LDFLAGS, for linker flags
mingw: use uintptr_t when converting a pointer to an int

win64 uses 32 bit long, so we cannot use a long to hold a 64 bit
pointer. Thankfully, there's a [u]intptr_t type available exactly
for these uses.
mingw: #ifdef unneeded #define in common.h

common.h has some #define when doing win32 build to workaround a few
missing functions on these systems. However, since mingw32 has some
of these, this causes either warnings about redefining preprocessor
symbols or wreak havoc in mingw headers trying to use these symbols.
This commit wraps these symbols in an #ifndef __MINGW32__ to avoid
using them on this platform.
mingw: add workaround for _ftime_s issue on mingw

mingw has a _ftime_s prototype in its headers, but no corresponding
symbol available at link time. Workaround this issue for now by
 #defining it to _ftime. This is untested on win64 where the workaround
may not be needed.
mingw: fix signed/unsigned comparison warnings
mingw: don't try to redefine alloca

mingw already has a #define alloca __builtin_alloca so trying to
redefine it triggers a warning.
mingw: workaround weird openssl build failure

If X509_NAME isn't undefined before including x509v3.h, very
weird compilation error occurs. It seems to be caused by duplicate
definitions for this symbols coming from wincrypto.h
Add log for invalid/expired tickets

Currently, when a ticket has already expired, or is invalid, there is
no qemu log to tell what went wrong. This commit adds such a log.

Fixes rhbz#787669
server: more logging about certificates used

This commit adds some log messages indicating which certificates
could be loaded (or not).

Fixes rhbz#787678
demarshal: fixed-size array are missing __nelements

A message with a fixed-size array, such as uint8 uuid[16] will
generate an invalid code, missing the __nelements variable. Make sure
that variable is defined.
Send name & uuid to capable clients

Add spice_server_set_name() and spice_server_set_uuid() that allows
the client to identify a Spice server (useful to associate settings
with a particular server)

The SPICE_MSG_MAIN_NAME and SPICE_MSG_MAIN_UUID messages are only sent
to capable clients, announcing SPICE_MAIN_CAP_NAME_AND_UUID.
Fix spice-protocol reference
Use SPICE_FOREIGN_MENU_SOCKET if it's available

If specified, use SPICE_FOREIGN_MENU_SOCKET environment variable over
snprintf(pipe_name, PIPE_NAME_MAX_LEN, PIPE_NAME,
Platform::get_process_id()); since it's impossible to guess the client
pid when spice-xpi launches the client as a grand-child (via script
etc).

This is also more aligned with the way we handle SPICE_XPI_SOCKET
location.