Detach race with new thread on UNIX b/c of late signal init w/o lock

Quoting from #2762

I have a unit test where there's a small chance that the thread doing detach will send the SUSPEND_SIGNAL to a newly created thread before its dcontext's signal_field is fully_initialized; the new thread discards the signal (can_always_delay[SUSPEND_SIGNAL] == true) and later initializes its signal_field, but the thread doing detach currently never retries to send the signal. So, this is kind of a workaround for a specific instance of #26 that results in DR deadlocking on itself.

Detach gets its list of threads from DR's internal list, and a new thread only adds itself while holding thread_initexit_lock in the thread init sequence where it initializes everything else, including the signal field. But: signal_thread_inherit is split off and called later, after the thread_initexit_lock has been released, and that's where the signal_field is fully_initialized. This leads to this race.

This issue covers trying to solve the race, either by pulling back the final signal init under the lock, or through some other means.

Xref #2270 (closed)