RDP: Add and use cursor renderer

Quoting the main commit here:

Currently, the session provides methods to render the cursor, while the
actual render sources for the cursor are in the instances of the
PipeWire streams for the recorded monitors.
In the initial version of the RDP backend, the current behaviour was
convenient, as gnome-remote-desktop only supported one monitor anyway
and since the session handling was single-threaded.

With the move to not handle any render operation in the main thread
anymore, which was done for performance reasons, the GMainContext of the
render thread needed to be exposed to the PipeWire streams.
And with the support of multiple monitors in the layout manager, where
each of them can be destroyed during the session, this created another
annoyance, that each render source in the PipeWire stream class needed
its own context to avoid race conditions, since the PipeWire stream
creation and destruction happens in the main thread.

In addition to that, when using multiple monitors, each monitor would
have its own render source for the same cursor. In a situation, where 16
monitors would be present, there would be 16 render sources for the same
cursor, while only one would be needed.

To get rid of these issues, introduce a cursor renderer class. The
design is relatively simple:
The class exposes a function to submit new cursor updates, and all
cursor related rendering is handled inside this class.
The PipeWire stream class will then in the next commit simply use that
submit function to submit new cursor updates, instead of managing cursor
updates themselves.

The cursor renderer class manages its own GSource for the cursor
handling.
In addition to that, the update paths are a bit abstracted to not
directly call the fastpath related methods.
Microsoft added in Windows 11 a new DVC for cursor updates
([MS-RDPEMSC]). The reason for this DVC is that in RDP only virtual
channel content is transported over UDP. So, this DVC allows submitting
cursor updates over UDP in the future.
Abstracting here the cursor paths will ease up the integration of that
mouse cursor DVC in the future.

To ease up integration of that mouse cursor DVC in the future further,
add a method to notify the cursor renderer, when the session is ready.
This is necessary, as it is not known whether that DVC is supported by
the client, unless the server side tries to open it.
If the client does not support that DVC, gnome-remote-desktop would have
to fall back to the fastpath for cursor updates.
With the mouse cursor DVC integrated, the class instance of the mouse
cursor DVC handling will use that ready-function.