[2019-12] [threads] Add back mono_threads_attach_tools_thread as a public API (#18074)
* [utils] Add back mono_threads_attach_tools_thread
In https://github.com/mono/mono/commit/
a5da7b21f4b6dbc5eaa09c2addee91b84dc1dbd5
we got rid of "tools" threads internally to the runtime.
However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.
This PR adds back an (external-only) limited form of tools thread.
The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)
However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.
Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.
mono_threads_attach_tools_thread should be called no more than once. It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.
Addresses https://github.com/mono/mono/issues/18011
* [threads] Make mono_threads_attach_tools_thread into a public API