Cleaner specification for RB experiments

[itoko]

This commit introduces the following API breaking changes that make the specification of StandardRB and InterleavedRB simpler and clearer.

• Make 2Q RB physical qubits direction aware
  This change allows users to be able to benchmark one direction of 2q-gate, e.g. cx(2, 1), by StandardRB. That means the RB circuits contains only cx(2, 1) if qubits=(2, 1) is supplied. Previously, if the backend supports both cx(1, 2) and cx(2, 1), the circuits may contains both of them, and the mix of them were benchmarked.
  • Pros: Faster circuit generation even for backends with non-bidirectional coupling graph by avoiding transpilation of full circuits, e.g. IBM Quantum processors with ECRGates.
  • Cons: Nothing as long users can define custom Clifford pulse gates easily. -> Better interface for RB with pulse gates #1032 Interleaved 2q-gate have to be always defined in the direction of basis 2q-gate of the device. If the device support only cx(2, 1) and if you want to interleave a custom cx(1, 2) pulse gate, you need to define a custom gate with inverted cx (control and target are swapped) as its definition and add its calibration (pulse schedule) onto qubits (2, 1).
• Change InterleavedRB to accept only basis gates for interleaved_element
  This change requires users to decompose interleaved_element before constructing an InterleavedRB experiment. This should not be demanding because they must know what gate (or sequence of gates) are actually interleaved and characterized.
  • Pros: Users can clearly see what they have interleaved, Simpler code.
  • Cons: Nothing as long users can define custom Clifford pulse gates easily. -> Better interface for RB with pulse gates #1032

[CLAassistant]

All committers have signed the CLA.

[itoko]

Superseded by #1288