Pyqrack

Testing with a multi-platform build environment, (such as Intel HD integrated graphics + NVIDIA or AMD GPU,) I have achieved stable fully-entangled 32-bit `QPager` interoperability on an Alienware m17, as an example of a cross-platform OpenCL context. ("Platforms" limit OpenCL buffer sharing, among other aspects, and are often grouped by vendor.) In the process, multi-device and cross-platform interoperability are likely debugged and improved in general, such as while specifying a device list with the `QRACK_QPAGER_DEVICES` shell environment variable. [(See the Qrack README.)](https://github.com/vm6502q/qrack#qpager-distributed-simulation-options)

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).