Pyqrack

The Qrack documentation previously stated that the sensible range for the `QRACK_QUNIT_SEPARABILITY_THRESHOLD` environment variable was 0 to 0.5; this was not true. Much earlier in development, this value scaled as probability to be in |1> (or |0>) eigenstate, hence the older instructions. Cleaning up the consistent use of the parameter, it actually _now_ represents (1 minus) the length of a state projected on a local qubit Bloch sphere, assumed to have unit radius. (So, the sensible values of the environment variable are 0 to 1, and have been for some time, up to consistent interpretation of the parameter's meaning by Qrack internals.).

Measurement sampling has also been optimized, such that, when all qubits are being measured, `QUnit` does not need to flush _any_ entangling buffers to produce the measurement distribution, such that subsystem footprints do not change in qubit count at all upon sampling.

FSim()` gate had bugged edge cases in `QEngine` and sub-optimal handling in `QUnit`: this has been fixed. (`QBdt::SumSqrDiff()` has also been parallelized.)

More of `QBdt` has been parallelized: `Compose()`, `Decompose()`, and `Dispose()` have been made parallel, as well as `SetQuantumState()`.

QBdt` probability checks and measurements have been parallelized. SIMD complex variables in the recursive tree are now passed by reference, to avoid duplication. The parallel stride of `QBdt`, controlled by `QRACK_PSTRIDEPOW` environment variable or `-DPSTRIDEPOW` CMake build parameter, has been rescaled to half (rounded up) of `QEngineCPU`.

All three "layers" of parallelism in `QBdt` have been successfully coordinated to work together without exceeding a thread count limit of the number of available hyperthreads (plus main/UI thread).

In the process of coordinating the layers of `QBdt` parallelism, a very long-standing edge case in CPU-based parallel for loops was "fixed": if the parallel for loop would only spawn one worker thread and then wait on it, it instead performs the workload on the main/UI thread. This might improve performance and stability on edge cases of `QEngineCPU`, as well.

Running large-scale benchmarks overnight, `QBdt` has not caused a single segfault, which we take to indicate sufficiently improved memory safety to motivate a patch release.