better unrolling in preset passmanagers

[ajavadia]

#5609 introduced a performance regression in time and quality of transpilation by doing unrolling at the end of transpilation level0, 1, 3.
This reclaims some of the performance back by doing the unrolling in an optimization loop. But the unrolling is necessary because the generated circuits were actually wrong before (they generated circuits that did not respect the basis). I added a release note to highlight this fact, and added tests (these tests would have failed prior to #5609 )

This also points to a need for better testing in the randomized transpiler passes to make sure the generated circuit is equivalent and respects the constraints in transpile().

[mtreinish]

LGTM, it would be good to include this in 0.17.0, but given the timing I think we just missed it. We'll have to include it in a 0.17.1 in a week or two. Just one small comment on the release note.

[mtreinish]

Before I merge this, I did have one question. Do we know which pass the gates outside of the basis were coming from? It doesn't really effect this PR because I think having the _unroll stage run on each iteration of the optimization loop makes sense, but I'm just curious if there is a pass we could/should make basis aware.

[mtreinish]

So I dug into this a bit, and the pass that was introducing U2s for level 0 and level 1 before was CXDirection which @ajavadia already removed to the preset pass managers and moved us to the GateDirection pass. However GateDirection is just now using H gates which are not guaranteed to be in the basis either so we still need to unroll to basis to ensure the output from GateDirection is converted to the specified basis set. I do think this raises bigger questions about how we track attributes of transformation passes in the passmanager. Unrolling in the optimization loop works fine, but I wonder if we want attributes like preserves_basis, approximate, etc as a top level attributes of a pass. I think we kind of hacked it in with the approximation_degree kwarg recently for approximate passes, but having a more formal interface for these kinds of attributes might be useful (I'll open an issue about this, or just reuse #5978 and make this part of that interface).