add OnceLockExt extension trait to help initialize OnceLock

[davidhewitt]

Possible alternative to #4512

The idea here is to add an extension trait to provide a method for std::sync::OnceLock which helps to initialize the OnceLock without deadlocking.

For users with MSRV below 1.70 we could possibly have a once_cell feature which does the same for once_cell::sync::OnceCell.

DRAFT: needs tests and more complete documentation.

[ngoldbaum]

Sorry for not commenting yesterday. I'm still getting my feet under me to have confident design opinions about PyO3.

There probably has to be a migration no matter what, even if it ends up just being a rename from GILOnceCell to PyOnceLock. Since the migration can't be avoided, I like that the extension trait allows use of the native rust standard library types, so I think I prefer this to #4512. After a deprecation cycle you'll be able to delete ~200 lines of code defining GILOnceCell in favor of this.

[colesbury]

There probably has to be a migration no matter what...

From reading #4512, it looked like that approach would not require users to change their code. I'd also be a bit concerned that this approach has more risk of deadlocks due to reentrancy or lock ordering issues. Once you start dealing with Python objects within a mutex or Once, those issues are a lot more likely because finalizers and weakref callbacks can call arbitrary code.

[colesbury]

It might also make sense to pursue both approaches. Make GILOnceCell thread-safe to make migration easier, but encourage people to use std::sync::OnceLock with this extension trait when appropriate.

[ngoldbaum]

would not require users to change their code

With #4512 I think we'd need a rename at least, since GILOnceCell no longer relies on the GIL. Renames are of course a lot easier for users to handle than completely changing semantics and removing a type :)