This is mainly because Glib::Threads (g_system_thread_new)
uses pthread on Un*x, but on Windows relies on GThreadWin32
(HANDLE)_beginthreadex
This later causes issues e.g. in BaseUI::run()
```
unhandled exception (type Glib::Error) in signal handler:
domain: g_thread_error
code : 0
what : Error setting new thread priority: The parameter is incorrect.
```
While POSIX defines a single contiguous range of numbers that
determine a thread's priority. Win32 defines priority classes
and priority levels relative to these classes.
pthread maps those to -15 .. +15 with the top six ones
corresponding to REALTIME_PRIORITY_CLASS and max being
THREAD_PRIORITY_TIME_CRITICAL
Note that the PA backend can USE_MMCSS_THREAD_PRIORITIES
and PBD::MMCSS::set_thread_characteristics() directly for
the I/O threads.
This is a glibc-only extension, so don't bother on other platforms.
Also, according to POSIX, PTHREAD_STACK_MIN is defined in limits.h, so
include climits just to be safe.
Some libraries use thread locals and hence increase the min
requirement.
This is seen on void-linux for example:
> linking a minimal program against cairo gives a
> __static_tls_size of 43008 bytes.
> Doing the same on Ubuntu focal and Debian bullseye,
> __static_tls_size is only 4608.
This new design will work even when threads that need to receive
messages from RT threads are created *after* the RT threads. The
existing design would fail because the RT thread(s) would never
be known the later created threads, and so signals emitted by the
RT thread and causing call_slot() in the receiver would end up
being enqueued using a lock-protected list. The new design ensures
that communication always uses a lock-free FIFO instead
threads created with this code can now just return a value as they normally would, and the
infrastructure will ensure cleanup. there is no longer any reason to call pthread_exit_pbd()
and so that has been removed.
