Reduce redundancy in act_on_fallback

[daxfohl]

Describe your design idea/issue

Ref #4371 (comment)

act_on_fallback accepts both operations and gate+qubit[] pairs. This generally causes some redundancy and occasional sloppiness in the implementations. In MPS simulator, we just promote gate+qubit[] to a GateOperation and work with that so that everything is then consistent.

This may be the best approach for all simulators, and we could do this in the act_on protocol itself, so that act_on_fallback only needs to accept operations. The main concern with that approach would be if it gets into an infinite loop of act_on(gate, qubits) -> act_on_fallback(gate_op) -> act_on(gate, qubits) -> .... However I don't think any act_on_fallbacks do this, nor should they, as gate.act_on gets called via gate_op.act_on in the initial pass, so there's nothing to be gained by doing this.

[daxfohl]

Once #4705 and #4702 are merged, we can actually go in the opposite direction. We require all Operations either expose a gate, or use _act_on_ to implement their own simulation logic, and pass the gate into act_on_fallback. This feels clean to me: we should have two types of operations:

• Operations that have a gate that performs its logic (if it's a quantum op)
• Operations that implement the logic in _act_on_ (if it's a control op, e.g. things that don't need to know which simulator they're using and execute the same logic regardless, like CircuitOperation or ClassicallyControlledOperation)

Then in protocols.act_on before calling the _act_on_fallback_ method, we get the gate from the action (which it MUST have (or be), to get to that point in the code), and pass that in as the first parameter to fallback. (We'd have to emit a deprecation warning here initially for external ops that don't have gates or act_on implementations).

But that allows us to clean up the code (no more passing qubits redundantly with operations), solidify the design intent, and have stronger guarantees on what gets passed into act_on_fallback.