The 3.0 release was the last one that still supports GTK2. For the
Windows builds the support to GTK2 was dropped in the previous release.
Let's do the same for the entire project now.

When starting virt-viewer in fullscreen mode, we generally try to
arrange guest displays exactly the same as client monitors. So if a
client machine has two monitors, we'll try to enable display 0 and 1 on
the guest (in that order). However, when using the configuration file to
map fullscreen displays to different monitors, the guest displays may
not be sequential, or there may be displays missing. For example,
consider the following configuration:

monitor-mapping=1:2;2:1

In virt_viewer_session_spice_fullscreen_auto_conf(), we were building an
array of GdkRectangles for the initial monitors that we want to enable
on the guest. We then configured the guest displays using the index of
the array for the as the id of the guest display. But when displays
are sparse or are out-of-sequence, the array index will not match the
>ntended display ID. This created problems where displays were arranged
incorrectly. By changing the simple array into a GHashTable, we can keep
the display ID together with the GdkRectangle until we need to use it,
and things will be configured correctly.

This regression was introduced by c586dc8c.

Fixes: rhbz#1267184

Make "main-window" a construct-only property of VirtViewerSessionSpice.
This allows us to set it in the constructor and encapsulate all of the
setup within the gobject constructor rather than doing extra work in the
_new() function.

Previously, there was a single function for controlling the enabled
state of a display: virt_viewer_display_set_enabled(). Unfortunately,
this function is used for two slightly different things:

 A. It informs the local display widget that the display has become
    disabled or enabled on the server. In other words, it tries to
    synchronize the 'enabled' state of the local widget with the actual
    state of the remote display.

OR

 B. It tries to actively enable a currently-disabled display (or vice
    versa) due to some action by the user in the client application.
    This causes the client to send a new configuration down to the
    server. In other words, it tries to change the state of the remote
    display.

There is some conflict between these two scenarios. If the change is due
to a notification from the server, there is no need to send a new
configuration back down to the server, so this results in unnecessary
monitor configuration messages and can in fact cause issues that are a
little bit hard to track down. Because of this, I decided that it was
really necessary to have two separate functions for these two different
scenarios. so the existing _set_enabled() function will be used for
scenario A mentioned above. I added two new
functions (_enable() and _disable()) that are used to send new
configurations down to the server.

Previously, when we received a new monitors update from the server, we
only called virt_viewer_display_set_enabled() for the displays that were
enabled. We simply assumed that those that were not enabled were already
set to disabled. This assumption is currently valid, but I have some
changes in the pipeline where this is not true. This change ensures that
we update the enabled state of all monitors when we get an updated
monitors conifguration.

When a display widget receives a new size allocation, we generally emit
a monitor-geometry-changed signal so that we can reconfigure the
displays. But if the widget for a *disabled* display is allocated,
there's no reason to send down a new configuration. We don't need to
emit this signal. This doesn't currently cause any problems, but I ran
into issues while testing some other uncommitted changes.

Coverity says:
Result is not floating-point (UNINTENDED_INTEGER_DIVISION)
interger_division: Dividing integer expressions "preferred->width * 100"
and "zoom", and then converting the integer quotient to type double. Any
remainder, or fractional part of the quotient, is ignored.

Coverity says:
You might overrun the 108 byte fixed-size string "addr.sun_path" by
copying "unixsock" without checking the lenght.
Note: This detect has an elevated risk because the source argument is a
paramenter of the current function.

Windows guests have monitor id = 0, so the debug log is always the same:
"creating spice display (#:0)" for all the displays.

The zoom can be changed by resizing the window (VNC / Spice without
the agent). It is necessary to recalculate the zoom level before
changing it, otherwise zoom operations will not work correctly.

Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=90582