Fix crash from concurrent nb::make_iterator<> under free-threading.

[hawkinsp]

The State class used by make_iterator is constructed lazily, but without locking it is possible for the caller to crash when the class type is only partially constructed. This PR adds an ft_mutex around the binding of the State type.

My initial instinct was to use an nb_object_guard on scope. Unfortunately this doesn't work; I suspect PyEval_SaveThread() is called during class binding and that releases the outer critical section.

[wjakob]

This change looks good -- however, can you lock some member of internals instead of using a static function-local variable? These involve additional locking added by the compiler, which is not wanted here.

[hawkinsp]

This change looks good -- however, can you lock some member of internals instead of using a static function-local variable? These involve additional locking added by the compiler, which is not wanted here.

No, it doesn't. A function-local static with a constant initializer does not need locking. See: https://godbolt.org/z/EKjMfW555

It's also not clear to me that any of the existing mutexes in internals are ok to use here: we're going to hold this lock while calling into the class binding code, which may acquire any of the remaining locks. If you'd like, I can add a new lock to nb_internals specifically for this purpose.

WDYT?

[wjakob]

That makes sense then. If forgot about the trivial nature of the constructor. Thanks for catching this!