Pyqrack

PyZX includes a "PhaseParity" gate within its internal set of gates. This gate can be implemented quite efficiently, over any qubit width, at the simulator level. The Qrack binaries have been updated to efficiently implement this gate, and the native implementation can be called directly via a `QrackSimulator` instance.

This debugs PyZX `Circuit` graph support. (With this work out of the experimental phase, I expect v0.5.0 to be the first version to truly support PyZX `Circuit` graphs.)

sim = QrackSimulator(pyzxCircuit=c)


where `c` is a PyZX circuit object. The circuit will automatically be simulated in the constructed `QrackSimulator` instance. This also allows loading from QASM and other intermediate representations supported by PyZX.

Also, reversing the state of v0.4.5, the none/any wheel includes _all_ available binaries from the author, while building from source assumes an installation of the underlying Qrack library from source.

This release refactors the concurrency handling in the underlying Qrack shared library interface binary. A "meta-" mutex synchronizes shared library simulator management by STL containers, as previously. However, the "meta-" mutex is now released once a new **`QrackSimulator`-specific mutex** is locked, for operations limited in scope to dispatching simulator methods. Hopefully, with (mostly intuitive) Python threading best practices, this reduces contention and increases stability in Python environments performing asynchronous threads of operations on different simulators.

It is important to note, PyQrack and Qrack will attempt to distribute new demand for simulation RAM to every available device in descending order of immediate device load, with the (environment-variable-selectable) default device preferred in load balancing contest ties. It is also possible, but not typically recommended, to control via environment variable whether PyQrack reactively redistributes unbalanced loads, instead of only redistributing through balancing **new** demand. (In the case of load-redistribution being activated, the device any load is currently on is preferred in case of redistribution ties, before default device.) Also, at a very low level, argument hooks for OpenCL kernels are device-specific, and cause thread contention on the combination of device and kernel call, like the kernel for the general single qubit gate, underlying many named single qubit gate methods. **See the vm6502q/qrack repository README for more information about these environment variables.**

The none/any wheel is `main` branch. However, we now package all wheel binaries together in the build-from-source distribution on PyPi, to maximize device market share coverage for the sake of users.

One of the OpenCL kernels in the underlying Qrack library was redundant with OpenCL v1.1 APIs. This kernel has been cut. (Compiled OpenCL program size can be a limited resource, so it is important to generally minimize program size, depending on trade-offs with performance, but there is no such trade-off in this case.)

Also, Linux shared libraries are now loaded according their local links (or "shortcuts"). This makes it possible, in the future, on Linux x86_64 and other systems, to properly alias shared libraries as per the conventions of the GNU linker.

This adds binaries that will automatically fall back from OpenCL to pure C++11 CPU-only simulation, if 0 OpenCL devices are present in the system. Also, an ARMv7 binary/wheel has been tested and is now fully supported.

Since the available wheels comprise the full extent of the PyQrack developer's ability to compile and support binaries, and the vast majority of systems that can use these binaries will select the appropriate wheels, `none_any` default wheel will match `main` branch and assume that vm6502q/qrack will be built and installed custom on the desired system.