Investigate TLS destructor order on Linux/Unix

[RalfJung]

@drmeepster reports that we are running the TLS destructors in a different order than what happens when you run rustc for real. However, to my knowledge the exact order in which TLS destructors are invoked is actually not documented. Still, we should ensure that is indeed the case, and add an appropriate comment in the code. (Or we could adjust the order, as that would make it consistent between Linux and Windows.)

[RalfJung]

I can confirm that on my system, tests/pass/concurrency/tls_lib_drop.rs via rustc prints

Dropping: 15 (should be before 'Continue main 1').
Dropping: 5 (should be before 'Continue main 1').
Continue main 1.

but via Miri it prints

Dropping: 5 (should be before 'Continue main 1').
Dropping: 15 (should be before 'Continue main 1').
Continue main 1.

Interestingly though, tls_pthread_drop_order passes on both of them.

The documentation explicitly states

The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.

so Miri is, I think, perfectly right here. It might even be good for test coverage to have a different order than rustc. But I will make the test not depend on the order.

In the future we might want to actually randomize the order in Miri.

[RalfJung]

Though it is strange that tls_pthread_drop_order passes on both -- that indicates they use the same order, but then something works differently in the other test. Hm...

[RalfJung]

Ah of course, tls_pthread_drop_order tests the pthread_key drop order, but actual thread-locals don't use pthread_key on Linux, they use this function and Miri hits the fallback path there by not providing those weak symbols.