[release/6.0] Ensure that tls_destructionMonitor is initialized if a thread is attached to the runtime.

[github-actions]

Backport of #65358 to release/6.0
Fixes:#64509

/cc @VSadov

Customer Impact

In a case when a thread has not been created by the runtime, but instead "wandered" into managed code - by the means of reverse p-invoke or the like, we do not have an entry point frame that would perform pre-mortem cleanup for the data that VM associates with the thread when the thread exits.
Instead we rely on c++ destructor for a thread-static variable that calls cleanup.

The issue here is that thread-static variable could be initialized lazily (it was observed on libc Linux) - if there is no "use" of the variable, there is no initialization and thus there is no destruction.

As a result the cleanup code is not called and we have a small, but steady leak every time a native thread that has seen managed code is subsequently terminated.

This change "uses" the thread-static sentinel variable whenever a thread is attached to the runtime, thus making the destructor called reliably.

Testing

I have verified manually that

• the repro scenario does cause a slow but steady memory leak (on Ubuntu 16.04 with 6.0 app)
• there is no leak after this fix is applied.

Risk

Low. We use the same cleanup strategy as before.
The change primarily ensures that destructor call cannot be optimized away if a thread was attached to the runtime.

[jeffschwMSFT]

Approved. We should consider for 6.0.x