The problem is that RedWindow::show calls the XLib MoveWindow function
on the window after it has been mapped, moving it to the location in
_show_pos. This is seen by the window manager as the application saying
I know exactly where I want my window to be placed, don't do placing for
me. Which causes the client window to always be shown at pos 0x0, even
though that may not be the best location.

What this patch does is:
1) It makes RedWindow::show not call MoveWindow when a window is
   first created normally and then shown
2) It makes RedWindow::show still call MoveWindow when:
   -when the window has been shown before, and was hidden for some
    reason (controller interface), and is now being re-shown
    so that it ends up being re-shown at its old position
   -when the window is a fullscreen window (screen.cpp always
    calls move on the window before showing it to set its position)
   -when the user switch from windowed mode -> fullscreen ->
    windowed mode again, to make sure that the windowed mode window
    is shown in the same position as before switching to fullscreen
    mode

This helps people who want to tell their windowmanager to do something special
with spicec, like make it sticky, or whatever, see:
https://bugzilla.redhat.com/show_bug.cgi?id=662452#c4

If connect_unsecure failed due to protocol version mismatch, don't try to
connect_secure with the same version, but retry (connect_secure or
connect_unsecure) with older version. catch (...) is handled by caller
at RedChannel::run().

This solves the following bug: when "new" Spice client (protocol version 2)
with given secure_port connects to "old" server which is not using the same
secure_port (or not using a secure_port at all), the client exits immediately.

In this scenario, the client first tries to use Spice protocol version 2 to
connect the unsecure port, and altough this fails due to version mismatch, it
tries to connect to the secure port with the same protocol version 2, which is
a wrong behavior, fails due to socket error 10061 (WSAECONNREFUSED -
Connection refused) and handled mistakenly by immediate exit, instead of
retrying with protocol version 1.

Currently when going / starting fullscreen if the guest resolution for one of
the monitors is higher then that monitor on the client can handle, we show a
white screen. Leaving the user stuck (unless they know the fullscreen key
switch combi) with a white screen when starting the client fullscreen from
the XPI.

This patch changes the client to fall back to windowed mode in this case
instead.