Most changes inside xrdesktop are caused by user input. Instead of littering everything
fine granular with locking, rather lock around gxr_action_sets_poll().
Since g_timeout callbacks run on the main thread, everything caused by user input is locked.

Remaining locks are necessary around:
* Adding and removing windows (locking is contained in XrdWindowManager)
* Callbacks on a timer, e.g. pointer tip animation

We use a recursive mutex, because adding windows can have two sources:
1. Newly created window is added by window manager integration
2. Opening the xrd button menu, caused by input which is already locked (on the same thread)