RDP: Add support for extending the desktop with a virtual monitor

Quoting the main commit here:

While the original intention for virtual monitor support in
gnome-remote-desktop always was support for headless sessions, another
use-case scenario occurred: Using a virtual monitor to extend the
current desktop to another device, allowing one to work with multiple
monitors on one desktop while, for example, only having one physical
monitor attached to the actual desktop system.
While the virtual monitor functionality in gnome-remote-desktop exists
since GNOME 42, the daemon could not be used to properly support the
extend scenario until support for multi-user- and single-user-headless
sessions was integrated, as only then different daemon types were
available. With 6e42f2adbf726160165fd82c073726fe22f6c53d, the user and
headless daemons don't share their settings backend anymore. This allows
an easy differentiation between those daemons and thus detecting the
scenario for virtual monitors.

So, add support for extending the desktop with virtual monitors by using
embedded cursors instead of submitting the cursor metadata and hiding
the system cursor on the client side.
In theory, using the PointerPosition update (warping the client cursor
position) should work too instead of using embedded cursors. However, in
practice, it seems that most clients don't implement handling for that
PDU.

Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/139

My original intention to implement this feature here was by rendering both the frame and the cursor to separate GFX surfaces, then blit the frame onto the onscreen surface, then the cursor. That should make mouse movement with embedded cursors more performant, as then we just need to tell the client to blit certain areas during mouse-movement-"frames". Unfortunately, RDP does not support alpha blending (figured that out way too late). Alpha channel data exists, but it can only be set, and not combined. That alpha data seems to be only effective for RAIL.

Considering that the slow devices (phones, tablets) support touch input, which is now implemented with !314 (merged), the (potential) cursor lag problem shouldn't be really an issue anymore, as there is now a way better (and more comfortable) input method available with it.

Supersedes: !167 (closed)