Adds patomic_signed_lock_free, patomic_unsigned_lock_free, and patomic_flag with wait/notify methods modelled after C++20. Implemented using futexes, falling back to a mutex+condition variable hash table if not supported. (Currently the hash table has a fixed size of 64, which we could increase if necessary, but we really shouldn't even have a fraction of that number of simultaneously sleeping threads...)
Other atomic types are unaffected at the moment, in part because futexes are really restricted to 32-bit ints on Linux anyway
Partial backport of 07545bc9e318d1799ceabe8838d04d7ad9297a45 for Windows, requires building with `--override USE_MEMORY_MIMALLOC=1 --override USE_DELETED_CHAIN=UNDEF` for optimum effect
Windows' malloc has awful performance. mimalloc is orders of magnitude faster, even faster than DeletedBufferChain. Therefore, only enable USE_DELETED_CHAIN on Windows when building without mimalloc.
On Linux, mimalloc doesn't appear to be measurably faster than glibc's own allocator. Both are marginally than DeletedBufferChain, though, and substantially faster in the multi-threaded case, so USE_DELETED_CHAIN is disabled there in all cases.
This typedefs to std::atomic<> when building with true threading, and uses a dummy implementation without.
This lets us use the full range of atomic operations offered by C++11, including explicit specification of memory fences. Using barriers lets the compiler generate more optimal code since currently we are using the quite strict sequential-consistent memory ordering for all operations. ReferenceCount has been changed to use the correct barriers (I hope). This may especially make a difference on weak ordering systems such as ARM.
Over time we should gradually replace the use of AtomicAdjust with the new patomic file.
The current value is not pickled. I might change my mind on this, but my thinking is that ConfigVariable doesn't really contain a value, it's just an accessor for a value from the config page, so the current state of the variables should be pickled with the config pages.
This redoes the handling of `obj[n] = item` to occur in InterrogateBuilder instead so that it doesn't prevent the same remap from being used as getitem.
This fixes the non-const variant of InstanceList[n].
See #1140 - I may revert this if someone can demonstrate a compelling use case (for current directory, you can use "." instead), but it seems to have the potential to cause unintuitive behavior.
We can't call PyErr_Restore() without a valid thread state, which won't exist in a custom thread if we just called PyGILState_Release(). Not sure how this has ever worked.
