Some fixes for the clipboard integration in RDP

This MR contains two fixes for the clipboard integration in RDP. Quoting the most important one here:

Currently, the rdp-fuse-clipboard creates the FUSE session in the main
thread and executes the FUSE loop in the FUSE thread.
However, when creating the FUSE session, FUSE creates thread specific
data.
This thread specific data lies in the main thread, but MUST lie in the
FUSE thread, as it is accessed there, especially, when the session
ends.
The problem, when the FUSE session ends is, that if a pending file
operation is happening, then FUSE cannot forcibly abort it.
Instead, it waits until the user in Nautilus confirmed the "OK"
message, that tells the user, that the data is not available any more.
While this situation can be worse (especially with headless sessions,
as gnome-remote-desktop would effectively freeze here), it is an
undefined situation, as the thread specific data is not available in
the FUSE thread.

To solve this situation, create the FUSE session in the FUSE thread.
This ensures that the thread specific data, that FUSE creates, is
created and accessed in the correct thread.
Also, since fuse_session_exit() does not directly stop the FUSE session
upon calling it, but merely sets an exit flag, call the stat command on
the FUSE root directory.
FUSE will always wait for an operation. Upon retrieving the operation,
it checks the exit flag.
If it is set, FUSE will exit the FUSE loop.

Since the user can unmount any (FUSE) mount any time, don't directly
destroy the FUSE session.
Instead, wait for the main thread here. This ensures that no race
conditions happen, where fuse_session_exit() might be called on a NULL
pointer or similar.
This waiting operation uses WinPR events and will not consume precious
CPU time here.
Also, do the same, when starting the FUSE session. This ensures that
the FUSE session always exists, when the FUSE clipboard has been
created.