feat!: Use a common struct for both QPU and QVM execution results

[MarquessV]

The original version of this PR attempted to abstract away the differences between QVM memory and QPU readout data by fitting them both into a common representation, where each register name mapped to a corresponding rectangular 2d-matrix where-in each row corresponded to the final state of that register after that shot.

It turns out QPU readout data is more complicated in that it treats each memory reference as a stream. These streams aren't delimited per-shot, so if the program isn't always performing exactly one readout to each memory reference per shot, it isn't clear from the readout data alone what the last value in each shot is. This is often the case for programs using features like mid-circuit measurement and dynamic control flow where a measure to a memory reference could occur more than once, or be skipped conditionally.

After some discussion internally, it became clear that the rectangular matrix this PR was originally attempting to build was indeed the preferred form, as it fits the type of math that is generally done on it. However, we can't escape from the realities of dealing with QPU readout data. In light of this, we've chosen to keep the abstraction, but only allow it if we can build it using the underlying readout data without making potentially erroneous assumptions. This gives users what they want in many cases, but forces them to build exactly what they need if their program calls for it.

This PR now stores the original data returned from either the QPU or QVM in a ResultData enum. Users can choose to turn this into a RegisterMap, which will build the "ideal" mapping of register names to rectangular matrices. If the underlying QPU data would be jagged, an error is returned, signaling to the user that they should build their own based on the program that was run.

The matrices themselves are built on the ndarray crate. This is not only convenient for working with the data in Rust, but it can also be passed to and from Python as a numpy ndarray using the numpy crate.

Closes #215

[Shadow53]

Really good work here!

I nitpicked a handful of things for you to address at your leisure.

The main non-nit I found is that it looks like your bounds checks suffer from an off-by-one error. Where possible, bounds-checked direct indexing should be replaced with a method that returns an Option instead.

Overall, really good stuff, and I think it'll streamline how people interact with returned data.

[Shadow53]

• One style suggestion
• One note about why ndarray doesn't have get_row(index) -> Option, etc. methods
• One response to the question of using usize vs u64 for MemoryReference::index in quil-rs

[notmgsk]

Looking good. Need to spend some more time with it, when I'm not tired :)

[jselig-rigetti]

LGTM, just some pyi questions

stale

[kalzoo]

It's almost there! This is excellent work.

Some small typos and a note re: visibility; otherwise, this is ready to go.

[Shadow53]

Left a handful of stylistic comments and a question or two.

Main reason for requesting changes is that I ran cargo check --all-targets --all-features locally and it surfaced some errors inside of tests. It may also be worth running cargo clippy with the same flags, just to be safe.

[MarquessV]

Main reason for requesting changes is that I ran cargo check --all-targets --all-features locally and it surfaced some errors inside of tests. It may also be worth running cargo clippy with the same flags, just to be safe.

Those checks fail for the same reasons on main. There is a manual-tests feature that has been neglected. Related issue here: #218

[Shadow53]

Three things:

1. Enum variants got turned into tuples in a pyi file
2. cargo deny check fails, in part due to the addition of numpy
3. cargo doc and cargo deadlinks --check-intra-doc-links show warnings. Not sure how many were there previously, but worth at least looking at.

[MarquessV]

I added the numpy license to deny.toml to satisfy cargo deny. The doc warnings and deadlinks are all pre-existing. The latter looks like it has to do with code generated by the pyo3 bindings.

[Shadow53]

LGTM