Releasing the thread global_lock from the module API

[Spencer Baugh <sbaugh@janestreet.com>]

Lisp threads all take global_lock while they are running Lisp code.
This is good and correct.

Lisp threads can also call module code.  This is also good and correct.

In other languages with an FFI and a global interpreter lock taken by
threads, such as Python, it's possible for a native function called from
the interpreter to release the global lock, and then re-acquire it
before calling any interpreter functions (or automatically re-acquire it
upon returning to the interpreter).

This allows for a limited form of actual parallelism: if a native
function is doing work that doesn't involve the Python interpreter,
e.g. doing numerical computations in native code, it can release the
lock so that it can run in parallel with other threads.  If the native
function needs to call a function which does involve the Python
interpreter, it can re-acquire the global lock around that call.

Could the same functionality be added to the Emacs module API?  Then
module code could release the global lock when doing Emacs-independent
computation, and re-acquire the lock when calling into Emacs.  This
would allow a limited form of parallelism: if a Lisp thread is calling
module code which releases the lock, then the module code could run in
parallel with the rest of Emacs on that thread.

This should be safe, because this is in effect already possibly through
thread-yield: that can be called from anywhere in a Lisp thread, and
releases the global lock, calls the operating system thread_yield
function, and then re-acquires the global lock.  If instead of doing
thread_yield, it did some computation, e.g.

int x = 0
for (int i = 0; i<999999; i++)
  x += i;

that would have the same effect as yielding, but the computation would
run in parallel with the main Emacs thread.  This is what would happen
if module code released the lock, did some Emacs-independent work, and
then re-acquired the lock.

As an additional bonus, this would allow the module API to extend Lisp
threads: if a C library provides some blocking function which does some
complicated form of IO, a module providing bindings for that C library
can release global_lock before calling that function, and then
re-acquire the lock after the function returns.  Then Lisp threads
calling this module function will not block the main Emacs thread.