Pyqrack

This release fixes an edge case that could cause `QBdt` with `QStabilizerHybrid` interoperability to throw a segmentation fault. (It also slightly optimizes edge cases in composing `QStabilizerHybrid` subsystems that might or might not have ancillary qubits.)

Interoperability between `QBdt` and other "layers" of Qrack has been fixed, (except for state vector simulation "under" `QBdt`, which has been temporarily disabled). This release allows one to use `QUnit`, `QUnitMulti`, `QStabilizerHbrid`, and `QBdt` simultaneously in concert, in the same simulator.

Relative the preview release, v0.21.13 fixes a couple of minor issues in code, and a big issue with the packaging of v0.21.12:
- _Very_ long control qubit index vectors (typically >256 elements) no longer have the potential to cause `bitLenInt` loops over these vectors to never reach the loop termination condition
- An optimized `QEngineCPU` overload has been restored for uniformly controlled gates
- In v0.21.12, Windows builds accidentally contained `main` branch code rather than Qrack API v8, (which is by now on main). Now, all binaries are built from the same API v8 code, short hash b73690e.

This release uses a preview version of the Qrack v8 API! The public PyQrack API is not changed, and most users won't notice a difference. However, the general point of Qrack v8 is to take lessons about "memory safety" from 5 years of Qrack development.

The biggest (internal) change is that Qrack public API methods no longer accept the combination of a raw (`const`) pointer and a secondary parameter to specify its length; rather, all such instances for `bitLenInt` index lists simply accept a `const std::vector<bitLenInt>&` type argument, to replace both parameters as a set. As a result, (without some very unlikely and "opportune" partial corruption of `std::vector` container instances,) it should never be possible in statically-linked Qrack to induce the library, with an invalid array length parameter, to read out-of-bounds past the end of the original pointer-to-`const` parameter. (Performance-critical sections _with an exact implicitly known length_ for pointer parameters, like in direct state vector copying, retain raw pointer-to`const` signatures.)

Qrack takes the recent popular and professional discourse surrounding Rust and "memory safety" seriously. More than a quarter million downloads of PyQrack later, the PyQrack developers can assert with confidence due to our track record in field deployment that double-free, access-after-free, memory leaks, and concurrency errors are typically _nil_, in any given iteration of the Qrack binaries under PyQrack. However, that doesn't mean we can't learn and benefit from past mistakes and new designs! The parameter patterns that Qrack v8 replaces, going back to the absolute earliest days of Qrack, have by now proven to be wholly an anti-pattern, with no particular benefit and at least one obvious problem. PyQrack users never directly interfaced with this anti-pattern anyway, but sleep soundly knowing that internal use of "lists" of qubit indices are bounds-checked for both the index "list" container and the subsequent OpenCL access patterns for which they code! (You rock!)

Sorry to spam releases again, but it very quickly occurred to me that I had missed cases of "memory safety" with regard to duplicate controls in ALU and other methods, as opposed to just elementary controlled gates in v0.21.10. Also, I updated my build environments, and Boost header versions were updated for Mac/Windows.

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.