Pyqrack

Hypothetical PyQrack builds have been cut, for which vm6502q/qrack builds but PyQrack hasn't or can't be tested. Momentarily, this only leaves us with x86_64 builds across Linux, Mac, and Windows, and 32-bit x86 builds for Windows. Every one of these variants has a separate wheel with a minimum of unnecessary binaries.

This adds a wheel specifically for Linux x86_64 systems that contains only the binaries necessary for that platform. In the near future, the same will be done for all systems we intend to support.

Also, the binary previously categorized as "ARM64" appears not to actually be for that platform. At least, it was compiled on a system presumed to be ARM64, but that system actually resolves a platform name of "armv7l". The binary selection has been updated accordingly.

This adds additional optimized gates to the API, so as to help expose all useful Qrack optimization directly to Python.

The `mcu` gate should internally cast its unitary angle parameters to `c_double`. This release adds the appropriate casts.

v.0.3.3
The `QrackSimulator()` `cloneSid` named argument didn't work. If the user attempted to clone, the `__del__` method tried to delete a simulator that didn't exist, within the shared library layer. This update fixes these bugs, and it does not require any shared library update.

This release updates the Qrack binaries for better default QUnitMulti device scheduling behavior, on systems with multiple OpenCL devices installed. This also adds a new environment variable to the underlying Qrack binary, `QRACK_ENABLE_QUNITMULTI_REDISTRIBUTE`, explained in the vm6502q/qrack README file. (Default behavior, without modifying the environment variables in use, should tend to work best, on most consumer home systems.)

The single call in the Qrack library to flush any OpenCL queue, immediately after every gate kernel dispatch, was returning an unspecified OpenCL error under high load. By simply removing this one queue flush call, no other errors arise, where we check _every_ OpenCL call for error codes. (This therefore appears to be a driver bug, but the behavior might be practically expected, if our gate kernels dispatch and flush very quickly.)