[40] rdp-fuse-clipboard: Handle FUSE lifetime object in FUSE thread

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.

(cherry picked from commit 5e669c29)