Raise an error on multi-qubit gates in `SabreSwap`

[jakelishman]

trafficstars

Summary

The documented behaviour of SabreSwap is that we assume that multi-qubit gates have already been decomposed. Previously, we silently ignored multi-qubit gates, most likely because this initial handling predated the introduction of the directive tracking in the Sabre interaction graph, so it was necessary to silently pass through barriers, which likely are multi-qubit.

The new Sabre interaction graph does more work to categorise the types of interactions, with the intention of compressing interactions that can statically be known to have no impact on the routing, to avoid multiple Sabre trials from having to work through them. This means that Sabre now very clearly sees a multi-qubit gate as it comes in, and can clearly distinguish it from a directive.

The removed test case has always provided a nonsensical input to Sabre, as it includes 3q gates without decomposing them. The test was originally trying to assert that measures that appeared in the lexicographical output of the OpenQASM 2 exporter remained lexicographically after any inserted swaps by routing (see gh-691 [^1]). The swap mapper was not (in that case) violating the data-flow requirements, and the general case of forcing measurements into the final position was the inclusion of BarrierBeforeFinalMeasurements anyway, it was just so happening that the conversion from data-flow graph back to sequential data happened to go in a different order.

[^1]: d27752197a: Measurements before swap mapping

Details and comments

Based on #14317