Pyqrack

As lead developer of Qrack and PyQrack, I have already admitted that there is a real reason to prioritize "memory safety" in a sense comparable to Rust, with which it might not be feasible to achieve exact parity, but at least a specific round of changes should be made to avoid obvious segmentation faults.

In this release, building on previous releases that prevented requesting any qubits outside of the range of allocated qubits in a simulator, it is now also _not_ possible without raising exception to specify the same control or target qubit more than once in the same gate, which would result in undefined behavior. Before this release, it might have been possible to cause OpenCL kernels and CPU equivalents to left-shift for an indefinite number of increments by specifying repeated control qubits, leading to potential out-of-bounds heap access attempts. Instead, the user now receives a `std::invalid_argument` exception before the out-of-bounds access is attempted, (translated to a Python exception, in PyQrack).

(Qrack v8 is planned to continue prioritizing manual memory safeguards like these. However, on an aside, when the statically-linked C++11 Qrack API accepts read-only `complex` type pointers with implicit array length, I suspect this greatly benefits FORTRAN LAPACK interface, as opposed to `std::vector`-based implementations or similar, and so maybe we _should_ compromise for the sake of performance when it is acceptably "safe enough.")

List initializers were also brought up to a better code standard in this release, though no warnings or errors surfaced as a result of the conversion, so this difference is likely more-or-less inconsequential.

In the course of preparing an alternate back end implementation, (with that back end not in this release,) various small imperfections became apparent in `OCLEngine` and `QEngineOCL`. Though a number of deviations from Qrack standards were corrected, only two changes in particular are likely to ever be noticed: a minor segmentation fault edge case was corrected in OpenCL callback usage, and `QEngine::clDump()` was modified to correctly track OpenCL memory usage for limits enforcement, whereas it previously relied on the destructor of `QEngineOCL` and might have missed more edge cases.

Unused declarations were also removed from OpenCL kernels, but no significant performance difference is likely. However, **re-compile your OpenCL kernels, if you use `qrack_cl_precompile`**.

A significant bottleneck in `QPager` simulations has been fixed: it is not always necessary to pin host memory for copying GPU-to-GPU in `Compose()`. This improves the case of `Compose()` with multiple GPUs that are in the same OpenCL "platform," (as would commonly be the case for 2 or 4 homogeneous GPUs in the same node, for example).

More checks have been added for whether requested qubit indices are out-of-bounds, in the underlying Qrack API. We can't guarantee unconditional "memory safety," as PyQrack is based upon a shared library C interface that accepts array parameters, for which it is dependent on separate array length parameters to know the allocated length of those array parameters. However, the goal is that, if `QrackSimulator` is given bad method arguments, PyQrack should still never raise a segmentation fault. These improvements (and particularly the related domain checks added in v0.21.7) should also act as a first line of defense against OpenCL buffer overrun.

Underlying `QEngineCPU`, `QEngineOCL`, `QStabilizer`, and `QBdt` types now check to make sure that qubit index arguments do not exceed the allocated number of qubits in a simulator. If they do, `std::invalid_argument` is raised by Qrack (and caught in the shared library C API, and re-thrown at Python level).

Historically, it turns out that the developer misunderstood C++ `const` pointer semantics, and `const pointer*` arguments have been made `pointer const*` arguments, as was originally intended. (The former is a pointer that is itself constant, as opposed to the latter meaning a pointer to memory that will not be modified.)

A redundant call to check probability in `TrySeparate()` was also removed, which increases performance.

(`QBdt` debugging is still underway, though use cases that _don't_ mix quantum binary decision tree qubits with ket qubits under `QBdt` might already work, as either fully "QBDT" qubits or fully ket qubits.)

With this release, `QBdt` ("quantum binary decision tree") passes all unit tests, both with and without "attached" ket qubits, and both with and without `QUnit` or `QUnitMulti` layer operating on top.

(We previously advertised that `QBdt` would become part of the default optimal stack, but there were still bugs at that time that interfered with benchmarks, and we have rolled back that change. However, the same effect can be achieved by turning the `QBdt` layer on in any layer stack and configuring it with the appropriate environment variables from the Qrack README.)

This release is only various micro-optimizations and one edge case bug fix:

- An edge case bug of `QPager::Compose()` was fixed, where qubit count was not previously correctly updated.
- In the more general case, `QPager::Compose()` has been made greedier, to sooner free memory with which it is finished, which might reduce the peaks of `QPager` memory-usage spikes.
- Micro-optimizations were made in the OpenCL program. **If you precompile OpenCL kernels, recompile your kernels, for this release!**
- A (blocking) `clFinish()` call in `QEngineOCL::DecomposeDispose()` was assessed to be unnecessary and removed, which might give a tiny improvement to the parallelism of internal and public API `Dispose()` calls.

**Again, note that If you precompile OpenCL kernels, recompile your kernels, for this release!** (I would guess that the old OpenCL program might be 100% functional anyway, but you would likely prefer to have the benefit of the new OpenCL micro-optimizations.)