This ordering is slightly relaxed from the default std::memory_order_seq_cst
but may not have any impact on typical x86 hardware.

Since the phase_lock is recursive, and we *always* need to acquire the lock
when transitioning to managed phase, the halting thread can just holt this
lock unconditionally while halting. That thread will then be able to run
stop-the-world garbage collection with the normal process which acquires and
releases the phase lock. This eliminates the second halt lock.

Recursive mutex under C++11 plays very badly with fork(), apparently. But we
must be able to do stuff like run garbage collection and Ruby code during
shutdown because we process Ruby finalizers, which may run pretty much
arbitrary Ruby code.

Hence, we need a mechanism to hold all threads except the halting thread but
also allow that thread to run arbitrary managed code, one function of which is
running the garbage collection code, which needs to stop the world for some
things, which relies on the ThreadNexus synchronization code, and on and on.

So we use an atomic variable that holds the thread's id and if the variable
already has a thread's id, that thread is the one who set it, and hence can
proceed confident that no other thread is running.