Integrate `quil-py` crate into `quil-rs`

[asaites]

Splitting quil-py from quil-rs was well-intentioned when this repo was first created, but over time it's become apparent it will be easier to maintain and offer better performance if these two crates are united, so that the Python wrappers generated for quil-rs come directly from the package itself.

[asaites]

These issues are all somewhat related, in the sense that post-integration, they are either closed, easier to achieve, or no longer relevant:

• The Python errors should be unified #461, TypeError and the resulted TypeResult are huge #452, and ProgramError is huge and has large differences in size between variants #453
  • This doesn't magically fix these, but should make it easier to improve error handling for consumers of either package.
• Alternative implementations for pickle/deepcopy #463
• isinstance(inst, Instruction) returns False for the types that make up the Instruction enum #148
  • This won't be true any longer, now that we can #[pyclass] the Instruction enum directly.
  • That said, it still might make more sense to implement a more Python-specific approach of subclassing a base Instruction class, as the enum usage is a little non-pythonic; on the other hand, just taking the PyO3 approach is much less code to maintain, and it means Instruction-level decisions for quil-py users can be written as a match statement, in much the same syntax as the Rust equivalent, and arguably that's a good thing -- but match has been in the language awhile now with relatively slow adoption.
• Support an immutable program #251
  • By moving to a newer version of PyO3, we can trivially make a #[pyclass] immutable for Python users.
  • It may make sense to make Program itself immutable for Python users, though it would require changing some aspects of the API. Users wouldn't be able to program_1 += program_2 any longer, so that might be a bummer, but it has an upside: the current implementation of that requires cloning both Programs, even though we could do with just one.
• Support Hash on Program #252
  • If we want to support Program hashing for quil-py, we'll need Program to be immutable for Python users.
• Benchmark potential compile time improvements. #165
  • In my experience, (rebuild) times aren't bad, even for release builds.
  • There's now less code overall, more opportunities to share implementations, and fewer macros to expand, so likely the build time is faster.
  • In any case, all quil-py related code is feature-gated so that Rust-dependents on quil-rs don't require a ton of extra dependencies. One consequence, however, is that we need to deal with PyO3's attributes that can't be cfg_attr'd away, and right now the best solution for that appears to be a procedural macro to strip them out in non-python builds.

[antalsz]

Re. immutable programs: making Program immutable is an extremely breaking change. The current idiomatic way to construct programs is

from pyquil import Program
from pyquil.gates import H, CNOT

p = Program()
p += H(0)
p += CNOT(0, 1)

(example from the Pyquil docs). This uses the Pyquil's Program, not quil-py's Program, but the former is a thin wrapper over the latter, as usual.

I think this is why both rigetti/pyquil#1826 and #251 suggest a FrozenProgram wrapper class, for when you're done building the program. I don't know if this is sufficient but it's certainly a lot simpler. I also found #384 while looking into this, which implemented a version of that functionality though was never merged.