Add rust representation for non-gate standard circuit operations

[mtreinish]

What should we add?

Now that we have a rust native representation for circuit operations we can build an work with circuits and gates directly in rust. However right now the only rust native operations defined are the standard gate library. These are the bulk of the cirucit operations used in Qiskit so there is a large gain from starting with just this set. But as we move more logic intro rust having a more complete representation of the standard circuit operations will be necessary.

Right now in rust there are 4 categories of object, StandardGate, PyGate, PyInstruction, and PyOperation. I think it would be best to add a new field StandardInstruction (or StandardOperation operation is a more descriptive term, but these will be analgous to the Instruction subclasses in Python) which we can use to add rust native representations of standard non-gate operations. This would house operations like Measure and Reset which aren't unitary operations but are similarly static.

The other option is to rename StandardGate to StandardOperations and add these operations to it. Personally I think there it's advantageous to leverage the type system to differentiate unitary gates from other operations like this (similar to how we use isinstance(op, Gate) in python). But I don't feel super strongly about it. There is also a tradeoff because we can only support so many variants in PackedOperation before we run out of space in the type so we do have to be careful about proliferating types there.

[mtreinish]

My other thought here is when thinking about types like UnitaryGate and maybe other operation types that we want to move to rust like that in the future is having a Box<dyn Operation> variant in PackedOperation. It gives us the flexibility to add any type without worrying about extending PackedOperation explicitly, and also opens up the possibility of custom operations defined in rust or otherwise outside of Python. However it does give up having static typing for everything we put in the circuit and we'd have to rely on the operation trait (and likely the name field) to differentiate types when an operation could be this box type.

I don't think if we added this it would preclude adding a fixed type for non-gate standard operations or any other core operation type, but since this issue is where we're talking about extending the data model first I figured I'd raise it here.