Control surfaces c'tor usually subscribe to signals e.g.
PortConnectedOrDisconnected. This happens after the parent BaseUI
is created, but before set_active() -> BaseUI::run() is called.
At this point in time there is no run_loop thread.
There are two options to handle AbstractUI::call_slot():
A. Queue the event in the event-loop, using the thread-local
request buffer of the caller. Then hope the BaseUI
thread is started, and calls ::handle_ui_requests() before
the memory pool runs out of space.
B. Handle the event in the calling thread. -- This may not be
rt-safe and may call functions with locks held by the caller.
It will however not accumulate events.
This takes approach (B). If _run_loop_thread is NULL, directly
handle the signal.
In the past, prior to 50abcc74b5, approach (A) was taken.
NULL never matched Glib::Threads::Thread::self().
This also reverts a prior attempt (e417495505) to address this issue.
84c51a1411