[GR-61894] Eagerly initialize native thread state.

[graalvmbot]

This change cleans up C API initialization state handling. In particular, the native PyThreadState will be initialized eagerly (best effort).

Unfortunately, if a thread is currently in a blocking I/O operation or something, we cannot wait for it to be finished. Therefore, we keep a fallback that lazily initializes the native thread state. The fallback is very unlikely because the initialization is submitted as thread-local action and most likely runs before any C extension function is called.

The main changes are:

• Initialize native thread state during C API initialization (i.e. initialize_graal_capi) on the initializing (usually the main) thread.
• Submit a Truffle thread-local action to initialize the native thread state on all already attached threads (see method CApiContext.initializeThreadStateCurrentForAttachedThreads(...)).
• Later attaching threads initialize their native thread state via PythonContext.attachThread.
• Split GCState and PyThreadState init liek CPython does. With that, reentrancy of the native thread state init is no longer possible.

This was motivated by a rare transient failure in C extensions where upcall PyTruffleThreadState_Get hit an assertion while trying to publish the address of the native TLS during lazy init of the native thread state.
The underlying issue was that thread-local tstate_current initialization on non-main threads was lazy and could re-enter the publication path. The new setup makes that initialization explicit and one-time per thread.