client thread created with static DR does not have clean TLS state at init

Using static DR and thus no -private_loader, a client thread created on Linux ends up inheriting the parent's TLS. This means that it looks at the parent's dcontext before its own is set up, which results in things like this rank order:

```
6172 os_request_fatal_coredump(msg);
(gdb) bt
#0 os_dump_core (msg=) at core/unix/signal.c:6172
#1 0x00005555557525ba in deadlock_avoidance_lock (lock=0x55555589ba10 , acquired=,
ownable=) at core/utils.c:611
#2 0x0000555555753049 in mutex_trylock (lock=) at core/utils.c:923
#3 mutex_lock_app (lock=0x55555589ba10 , mc=0x0) at core/utils.c:858
#4 0x0000555555638a00 in dynamo_thread_init (dstack_in=0x5555361aa000 "@\240\032\066UU", mc=0x0, client_thread=1 '\001')
at core/dynamo.c:2208
#5 0x000055555572d4e8 in client_thread_run () at core/unix/os.c:3678
#6 0x00005555555b1e70 in dynamorio_clone () at core/dynamo.c:3035
```

In this case the parent thread is holding global_alloc_lock as part of regular init.

I believe this only ends up causing asserts in debug build and has no release build problems.