This fixes a "too many sections" issue
```
Fatal error: can't write 159 bytes to section .text of build/libs/ardour/luabindings.cc.1.o: 'file too big'
x86_64-w64-mingw32-as: build/libs/ardour/luabindings.cc.1.o: too many sections (36781)
```
The old code assumed that the thread that created a request buffer for a given
signal-emitting thread would be the latter thread, and thus a thread-local
pointer to the request buffer could be used. This turns out not to be true: the
GUI thread tends to be responsible for constructing the request buffers for
pre-registered threads.
That mechanism has been replaced by using a RWLock protected map using
pthread_t as the key and the request buffer as the value. This allows any
thread to create and register the request buffers used between any other pair
of threads (because the lookup always uses a pthread_t).
The symptoms of this problem were a signal emitted in an audioengine thread
that was propagated to the target thread, but when the target thread scans its
request buffers for requests, it finds nothing (because it didn't know about
the request buffer). In a sense, the signal was successfully delivered to the
target thread, but no meaningful work (i.e the signal handler) is performed.
libardourcp and now libardour_midisurface are not control
surfaces, but helper libraries for those.
They need to be deployed to the library folder (shared between
ctrl surfaces) and not scanned as ctrl surfaces at runtime.
Most wscripts use
#!/usr/bin/env python
Use that consistently.
The wscripts are not executed directly and do not need the shebang path,
but it might guide editors and other tools to recognize the files as
being Python-ish.
Found via `codespell -q 3 -S *.po,./share/patchfiles,./libs -L ba,buss,busses,doubleclick,hsi,ontop,ro,seh,siz,sord,sur,te,trough,ue`
Follow-up to 364f2f078
