Full support for control flow in transpile

[jakelishman]

What should we add?

Over the course of the epic:

• Track adding control flow passes for optimization level 1 #8630

we added support for control-flow to the transpiler at optimisation levels 0 and 1. For full support, we need to bring the missing passes up-to-speed as well. This epic tracks the other components to achieve that.

For the purposes of this issue, we particularly need SabreSwap upgrading. For optimisation level 2, we need the optimisation passes CommutationAnalysis and CommutativeCancellation, and optimisation level 3 (and some less common transpiler options) make up the rest. We do not need to add support for control-flow to all of the scheduling passes right now, because Qiskit control-flow is only supported by IBM hardware at the moment, and scheduling this is handled by the IBM provider.

When these are updated, we should also make sure that the corresponding gated checks in the preset pass-manager constructors are corrected.

Sub-epics:

• Enable control flow in optimization_level=2 #9431
• Enable control flow in optimization_level=3 #9432

Tracked issues:

• Support control flow in SabreSwap #9419
• Support control flow in Python components of SabreLayout #9421
• Restore level 1 layout/routing default to SabreSwap #9422
• Support control flow in CommutationAnalysis and CommutativeCancellation #9423
• Support control flow in DAGCircuit.collect_runs #9425
• Support control flow in ConsolidateBlocks #9426

Low priority related issues - these should not be prioritised, and are not required for this epic:

• Support control flow in LookaheadSwap #9429
• Support control flow in BasicSwap #9430

[jlapeyre]

EDIT: #10355 uses a completely different approach. So the comment here is irrelevant to this epic.

The current implementation of ConsolidateBlocks requires that information regarding nodes on the DAG persists across passes, using the usual properties mechanism. But the blocks of ops inside control flow ops (need a good name for that!) are QuantumCircuits. If you convert them to DAGCircuits each time you need to analyze or modify them in a pass, the relevant node ids will not be the same across passes. Trying to refer to the node ids from a previous pass would result in an error. There's also the issue of performance degradation from repeated conversion between circuits and dags. But that is a secondary concern.

We might try something like this:

1. Allow the bodies of control flow ops to be DAGCircuits, rather than restricting them to QuantumCircuit as is currently the case. Maybe making IfElseOp a parametric type is reasonable. It seems Python seems to be evolving toward better support for this. But, I imagine there are some downsides. Or more simply, allow the two types in the bodies and do isinstance checks. This will add a bit of complexity and bug-proneness.
2. Modify circuit_to_dag to recursively convert control flow ops to use DAGCircuit.

Then these lower-level DAGs will have a persistent identity. And we can manipulate them at a lower level. Eg. within DAGCircuit. This should be cleaner than doing conversion and recursion into bodies repeatedly at higher levels.