Pyqrack

In this release, more `QPager` edge cases can be simulated without exhausting VRAM footprint. "Optimization layers" have been rearranged slightly, such that `QMaskFusion` defaults to off and `QPager` is switched in `QHybrid`, alongside CPU and single GPU segment simulators. The binary size is also smaller.

Also, the Windows 32-bit wheel will no longer contain the Windows 64-bit binary, from hereon. (The Windows 64-bit wheel will continue to contain both 64-bit and 32-bit builds.)

v0.10.14 was a false start, in that qubit widths that were in the domain of `Qrack::QPager` still didn't generally work.

In v0.10.15, we revert recent changes to the `Qrack::QEngine::ShuffleBuffers()` method used by `QPager`, to fix this issue. In the interim since last release, we also found a way to avoid copying state vectors in crossing the threshold from non-paged to paged qubit widths, while using Schmidt decomposition.

The major drawback is that use of `ShuffleBuffers()` is currently neither threaded nor asynchronous. (The hope was to convert _from_ threaded operation, which began to use too many hyperthreads, _to_ an asynchronous method, though the method call is currently serial and blocking.) However, users might notice better `QPager` performance overall than in weeks past, and conversion of `ShuffleBuffers()` to an asynchronous method is still planned.

A deadlock in Qrack's `QPager` has been fixed, which affected circuit simulations besides the QFT. Also, Qrack's `QEngineCPU` simulator now uses `std::unique_ptr` for RAII state vectors. (This was previously difficult with C aligned allocation, but Qrack is generally RAII by paradigm, by version 7.)

PyQrack has finally just about reached parity with the underlying C++ Qrack library's capabilities, as on QFT + measurement. This is a small code change, and I apologize again for rapid release iterations, but an additional qubit is effectively available on many PC and Mac systems with GPUs, as a result of this release. Further, this might scale to multi-device simulation, particularly with the `QRACK_QPAGER_DEVICES` device list environment variable defined in the vm6502q/qrack README.

Sorry to iterate twice in a day, but there was a deadlock condition in high-width GPU simulation, easily fixed. When I noticed that `QPager` could effectively simulate at least 1 additional qubit on GPU, when the deadlock was fixed, I prioritized immediate release.

C++ Qrack has historically been stable at higher qubit widths than PyQrack. While this might still be the case, qualitatively, PyQrack on a single GPU can now effectively address an additional maximum qubit of simulator width, probably on most-to-all systems. With multiple GPUs, the ceiling might even be raised further, compared to all prior releases.

Remember that C++ Qrack environment variables apply alike to PyQrack, as documented in the [Qrack README](https://github.com/vm6502q/qrack/blob/main/README.md).

export QRACK_SEGMENT_GLOBAL_QB=1

might be appropriate for a (Linux) environment variable, here, which splits maximum allocation _segments_ by a factor of 2 in size, (but not overall maximum allocation).

Over the weekend, I attempted to clean up inline methods in the underlying Qrack C++ library. Doing so led to instability in Qrack's `QPager` layer, due to spawning too many CPU threads. (Likely, higher peak thread usage is because of slightly better performance.) I corrected this instability by making `QEngine` methods like `ShuffleBuffers()` asynchronous, so `QPager` does not need to dispatch any threads of its own for gate methods. As a result, `QPager` is likely more stable, for peak thread dispatch, than even before reviewing inline methods.