Support control flow in SabreSwap

[jakelishman]

What should we add?

Part of #9417.

In #8418, with follow-ups in #8891 and #8906, we added control-flow support to StochasticSwap. Our preferred router is actually SabreSwap, which is one of the blockers for control-flow support in optimisation levels 2 and 3. In #8830 we also had to modify the logic for optimisation level 1 to restore old behaviour of using DenseLayout and StochasticSwap as the default layout+routing stages if control-flow was detected. This issue is complete when SabreSwap can route all the same circuits that StochasticSwap can.

Details

From #8418, the approximate method we used could be described as:

1. split up the circuit into topologically-ordered blocks, where a block is either a list of non-control-flow instructions, or a control-flow construct

2. go through the blocks in topological order, routing non-control-flow blocks like normal

3. when a control-flow block is encountered, iterate through its contained blocks (in any order). For each:

   1. widen the block to contain all qubits
   2. recursively apply the routing pass on it, tracking the output order
   3. insert swap-mapped permutation circuits at the end of each block to bring them all back to the same layout. Loop constructs, and non-exhaustive if statements need to have their final layout match their starting layout.
   4. remove qubits from each block that are idle in all blocks (all blocks must act on the same circuit resources - qubits and clbits)

   Now the control-flow block can be placed into the outer circuit.

Note that step 1 is mostly implicit in StochasticSwap; we don't actually add a new structure to represent the top-level blocks, we just iterate through it transparently. For now, we probably want to try something similar for SabreSwap. The vast majority of SabreSwap is implemented in Rust, but there is a small Python layer to it as well. With this in mind, there are two main options:

1. extend all the Rust data structures to be able to represent control-flow across the API boundary, and implement all the new logic on the Rust side.
2. leave the Rust untouched, and implement all the new logic on the Python side.

Option 1 is likely the more long-term preferred option, since it's likely to be significantly faster, and will be easier to iterate and evolve as we design more efficient methods for routing circuits that contain control-flow. However, that does involve significant Rust knowledge, and this would likely be a very tricky place to get started with Rust. We also don't have a clear vision on what these new data structures would or should look like.

Option 2 is easier in the short term, and may let us re-use some of the work already done in StochasticSwap to handle the routing. Off the top of my head, I'd definitely suggest trying this way first if the implementor is more proficient in Python than Rust. We can always port the structures to Rust later.

Longer term

Option 1 is the long-term goal here, but we don't have to jump to it straight away. To work with the new parallel Rust internals of SabreLayout that use the Rust SabreSwap internals directly, we will need the new data structures done in Rust. However, the old Python-space components of SabreLayout are still available, and so initial control-flow support in SabreSwap can just be in Python space for this first pass of support.