Fix tests for cargo stress on free-threaded build

[ngoldbaum]

refs #4265

The free-threaded build has a lot of flaky tests at the moment and I'm trying various strategies to find them. Running cargo test in a bash while loop works well, but cargo stress also seems to find interesting bugs. This fixes issues that cargo stress hits quickly on my local setup.

The changes to test_datetime_imports can be hit in a regular gil-enabled python build, the test uses the filesystem assuming no other instances of the test function are running simultaneously. I updated it so it will create directories with unique names.

The changes for the decref pool tests are because in the free-threaded build other threads are free to process the decref pool at any time, it's no longer locked by the GIL. That's fine, it doesn't matter if the owning thread or another random thread processes the pool. It does mean that the assertions in the tests are no longer always true and depend on timing. I added comments where I had to think really hard about scenarios where the assertions don't hold.

There's also one assertion that is changed because the Py_DECREF calls on the pending decref pool can happen concurrently with calls to Py_REFCNT in other threads, making the result of Py_REFCNT racy. The mutex on the pending decrefs pool is implicitly released when pending_decrefs is dropped before calling the C API here:

pyo3/src/gil.rs

Lines 276 to 281 in 2f5b45e

	let decrefs = mem::take(&mut *pending_decrefs);
	drop(pending_decrefs);
	for ptr in decrefs {
	unsafe { ffi::Py_DECREF(ptr.as_ptr()) };
	}

[davidhewitt]

Thanks!

[davidhewitt]

LGTM, thanks!