GitLab

Locking will only happen after calling xrd_render_lock_init ()
and will stop after calling xrd_render_lock_destroy ().

Otherwise, locking functions are noop.
Only XrdSceneClient uses a render thread, so only scene client will call lock_init.

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 triggered by action set data run on the main thread,
the render thread is blocked while user input is processed.

Remaining locks are necessary around:
* Adding and removing windows (locking is contained in XrdWindowManager)

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 (b press) which is already locked on the same thread

e.g. when the GxrBackend is not found.

To be able to know which GxrApi the GxrContext is running on, first
create the GxrContext, and then check.
This creates a GxrContext before XrdSceneClient or XrdOverlayClient,
which was duplicated code anyway.

When another scene app is quitting and xrdesktop is running in overlay mode,
xrdesktop should switch to scene mode, only if the user wants to run scene
mode in the first place, i.e. if overlay mode is not the default.

Only the scene mode uses reupload and render threads.
When switching from scene to overlay, those threads have to be stopped,
when switching from overlay to scene, those threads have to be started.

Initial upload of window textures is done in either case now.

This prevents a crash when rendering runs in a thread and tries to
access the list of controllers while one is initialized.

Update private headers.

Add upload thread that changes textures in scene client mode.

Add version to config file.