This commit adds a new function quantum_volume used for generating a
quantum volume model circuit. This new function is defined in Rust and
multithreaded to improve the throughput of the circuit generation. This
new function will eventually replace the existing QuantumVolume class as
part of Qiskit#13046. Since quantum volume is a circuit defined by it's
structure using a generator function is inline with the goals of Qiskit#13046.

Right now the performance is bottlenecked by the creation of the
UnitaryGate objects as these are still defined solely in Python. We'll
likely need to port the class to have a rust native representation to
further speed up the construction of the circuit.

Co-authored-by: Julien Gacon <gaconju@gmail.com>

The previous commit was relying on the behavior of the annotations
future import but neglected to add it. This commit corrects the
oversight.

The previous implementation had 4 heap allocations for each random
unitary constructed, this commit uses some fixed sized stack allocated
arrays and reduces that to two allocations one for q and r from the
factorization. We'll always need at least one for the `Array2` that gets
stored in each `UnitaryGate` as a numpy array. But to reduce to just
this we'll need a method of computing the QR factorization without an
allocation for the result space, nalgebtra might be a path for doing
that. While this currently isn't a bottleneck as the `UnitaryGate`
python object creation is the largest source of runtime, but assuming
that's fixed in the future this might have a larger impact.

When executing in the serial path we previously were working directly
with an iterator where the 2q unitaries we're created on the iterator
that we passed directly to circuit constructor. However testing shows
that precomputing all the unitaries into a Vec and passing the iterator
off of that to the circuit constructor is marginally but consistently
faster. So this commit pivots to using that instead.

This commit fixes two issues in the reproducibility of the quantum
volume circuit. The first was the output unitary matrices for a fixed
seed would differ between the parallel and serial execution path. This
was because how the RNGs were used was different in the different code
paths. This change results in the serial path being marginally less
efficient, but it shouldn't be a big deal when compared to getting
different results in different contexts. The second was the seed usage
in parallel mode was dependent on the number of threads on the local
system. This was problematic because the exact circuit generated between
two systems would be different even with a fixed seed. This was fixed to
avoid depending on the number of threads to determine how the seeds were
used across multiple threads.

The last fix here was a change to the error handling so that the
CircuitData constructor used to create the circuit object can handle a
fallible iterator. Previously we were throwing away the python error and
panicking if the Python call to generate the UnitaryGate object raised
an error for any reason.

Co-authored-by: Julien Gacon <gaconju@gmail.com>