race on detach with new threads on Windows

#2600 fixed this race on UNIX. On Windows, however, we cannot use the same approach of a counter because we cannot see all thread creations due to externally injected threads. Windows does have init_apc_go_native, which helps, but it still leaves a race window (one which shows up on the new api.detach_spawn test).

I tried an approach of catching threads in thread init post-detach and sending them native (via a return through the APC hook), which won't work for a shared library detach but I was hoping would work for a static lib. However, the api.detach_spawn test showed a problem: if we've attached to a thread but it hasn't been scheduled yet, it's still pointing at thread_attach_takeover_callee. We can't just return there b/c it's not a hook: it's just a gencode routine. We also can't use the existing AFTER_INTERCEPT_LET_GO_ALT_DYN because it requires a static target and we need a dynamic target for each thread's attach point.

Start by comparing the UNIX fix in #2600 with the Windows path around init_apc_go_native. Reproduce the race with the api.detach_spawn test, then trace thread_attach_takeover_callee and AFTER_INTERCEPT_LET_GO_ALT to understand the dynamic-target constraint. Done means the Windows detach path has no race and the test passes, but the implementation approach is not specified.

Written by the indexing model from the issue text.