Add support for BackendV2 and Target to transpiler

[mtreinish]

What is the expected enhancement?

With the BackendV2/Target interface being added in #5885 we have more data available to the transpiler to inform the passes on the characteristics and constraints of a backend. However as of right now none of the passes in the transpiler know how to take advantage of this extra information. We need to update the transpile()/PassManagerConfig/preset pass manager constructors to deal with passing a Target object around and then update some passes to leverage the extra information.

Primarily for 0.19.0 we probably will need to update the BasisTranslator to respect the qargs of an instruction, CheckGateDirection/GateDirection to work with Target instead of a coupling map, and optionally UnitarySynthesis to get noise parameters from a Target. While pretty much every other pass will need to be updated too those can happen over time the first 2 should be enough so transpile() will respect a heterogeneous gate set which is our goal for 0.19.0.

[mtreinish]

I'm changing the target here to 0.20.0, because while the first piece of adding the target to the PassManagerConfig is done in #7227 and the basis translator will have initial support for working with a Target we still need to update all the other passes and start us down the path to making the target used everywhere which will be a work item for 0.20.0

[mtreinish]

So for this issue I think we should concentrate just on passes that are either basis aware or noise aware. These are places where the target provides a more rich set of information and to do a thorough job compiling for a target based backend we need the full set of information instead of just the global backwards compatibility shims. For example, things like layout and routing passes don't really gain much by using the target as they operate on a global coupling graph and rely on later passes to adjust things for basis gates, etc (the exception being noise aware versions of these passes).

Once we've migrated the passes where there is a functional need I feel like we can close this issue. After this we should look at expanding the functionality in the transpiler based on the extra information in the target. The big use case is updating things to leverage over complete basis gates (i.e. have the transpiler pick the best gate if there are multiple choices available) or to work with fixed angle tuned variants of arbitrary rotation gates.

I've made a list of these passes here:

• [X] GatesInBasis (https://github.com/Qiskit/qiskit-terra/pull/7548)
• [x] UnitarySynthesis (https://github.com/Qiskit/qiskit-terra/pull/7775)
• [x] ~CommutativeCancellation~
• [x] Optimize1qGatesDecomposition (#8917)
• [x] ConsolidateBlocks (#7778)
• [x] UnrollCustomDefinitions (https://github.com/Qiskit/qiskit-terra/pull/8784)
• [x] MSBasisDecomposer (although I expect we might want to to deprecate this pass now that we have the basis translator)
• [x] BIPMapping
• [x] DenseLayout (#7776)
• [x] VF2Layout (https://github.com/Qiskit/qiskit-terra/pull/7735)
• [x] NoiseAdaptiveLayout
• [x] CrosstalkAdaptiveSchedule
• [x] Optimize1qGates
• [x] Optimize1qGatesSimpleCommutation (#8917)
• [x] Unroller
• [x] Unroll3qOrMore (https://github.com/Qiskit/qiskit-terra/pull/7997)

(I only grepped for keywords and I might have missed some, so feel free to expand the list)

[HuangJunye]

I can help you with some of these transpiler passes

[mtreinish]

I've crossed CommutativeCancellation off the list because I'm not sure there is anything extra a target can add to the pass. It is used solely to know which z rotation gate to use in the cancellation if there aren't any in the circuit: https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/transpiler/passes/optimization/commutative_cancellation.py#L72-L80 The pass isn't really basis aware per say because by default if there is an rz, p, or u1 in the circuit the pass will use one of those (whichever is first in the circuit) regardless of the basis. The underlying assumption here was probably that this pass was written assuming the circuit was already basis translated prior to execution so that looking at the circuit's gates kind of proxied checking the basis set. The pass could (and arguably should) be rewritten to not take a basis at all and just always use one of those z rotation gates and require that basis translation be run after it. We already run the basis translator in all preset pass managers because other optimization passes don't always emit gates in the target basis.

[mtreinish]

With #9263 recently merging this is finally complete