ORC JIT crashes with non-trivial dtors on thread-local function values

A JIT-compiled function with a thread-local variable within will crash if the thread-local has a non-trivial destructor. The crash happens in the dtor itself, presumably via `atexit`.

Based on discussion with Lang, the theory here is that the thread-local variable triggers an `atexit` (or similar) registration for its dtor, but that dtor runs after LLVM has been torn down, leading to UB.

```cpp
❯ cat thread-local-dtor.cpp
struct foo { ~foo() {} }; // making this = default will avoid crash
void hello() { thread_local foo f{}; }
hello();

❯ ./build/llvm-install/usr/local/bin/clang-repl < thread-local-dtor.cpp

Segmentation fault (core dumped) ./build/llvm-install/usr/local/bin/clang-repl < thread-local-dtor.cpp
```

The backtrace, from gdb.

```
(gdb) bt
gdb.error: DWARF Error: Can't read DWARF data in section .eh_frame [in module ]
#0 0x00007ffff7fb2050 in foo::~foo() ()
#1 0x00007fffeeb525ef in __call_tls_dtors () from /usr/lib/libc.so.6
#2 0x00007fffeeb52a27 in ?? () from /usr/lib/libc.so.6
#3 0x00007fffeeb52a8e in exit () from /usr/lib/libc.so.6
#4 0x00007fffeeb39748 in ?? () from /usr/lib/libc.so.6
#5 0x00007fffeeb39879 in __libc_start_main () from /usr/lib/libc.so.6
#6 0x00005555555599b5 in _start ()
```

## Environment info
* LLVM: Reproduced on 22 and also main, so I don't believe this is a regression
* OS: Linux x86_64 (NixOS)

Start by reproducing the crash with the thread-local-dtor.cpp example through build/llvm-install/usr/local/bin/clang-repl, then inspect the ORC JIT and thread-local destructor or atexit handling involved in the backtrace. Done means the example no longer crashes on exit and a regression test covers a JIT-compiled function with a non-trivial thread-local destructor.

Written by the indexing model from the issue text.