gh-152741: Fix data race on PyThreadState.thread_id during thread bind

[tonghuaroot]

bind_tstate() sets tstate->thread_id (and native_thread_id) without
synchronization while the thread state is already published to
interp->threads.head and the thread is not yet stop-the-world-stoppable. The
stop-the-world readers _PyThread_CurrentExceptions (sys._current_exceptions())
and _PyThread_CurrentFrames (sys._current_frames()) read t->thread_id, so the
bind store races the reader (reproduced under a free-threaded ThreadSanitizer
build; see gh-152741).

Publish thread_id/native_thread_id with a relaxed atomic store in
bind_tstate() and read them with a relaxed atomic load in the readers that walk
the thread list — _PyThread_CurrentExceptions, _PyThread_CurrentFrames, and
PyThreadState_SetAsyncExc — matching the relaxed-atomic treatment already used
for tstate->state. thread_id is a standalone scalar written once during attach
(never reset on unbind) and read only as an identity value, so relaxed ordering is
sufficient. In the default (GIL) build the FT_ATOMIC_* wrappers expand to plain
loads/stores — no overhead.

Verified TSan-clean: 0 races across 32 short reproducer runs + 4 full 30s windows
(vs the race firing on every unpatched run); functional and test_threading
smokes pass under the FT+TSAN build.