Stop building decomposition dag at instance creation

[mtreinish]

Summary

This commit adjust how we define decompositions for gates. Previously we
ran a function which built a dag of the decompositions during __init__
for the gate class. This meant we'd build a new dag every time we
created a new gate, which for large circuits would start to add up.
However, the decompositions are static for most gates and we only need
to run it once. To accomplish that this commit makes the decompositions
a class defined parameter and removes it from __init__. This way we only
ever build the decomposition dags once unless explicitly needed.

Gates that are not touched: crz, cu1, cu3, rx, ry, rz, rzz, u1, u2, u3,
are left alone because the decomposition depends on run time variables
in the instance and this optimization provides no benefit.

Details and comments

Fixes #1729

[ajavadia]

luciano sped things up in #1455 by making sure that _define_decompositions() is only called upon request (i.e. when the unroller needs to make an unrolling decision). But it is still per instance, not per class. So there's still merit to this PR to get further improvement from some classes (those that don't have any parameters).

[mtreinish]

ugh, well that makes rebasing this fun :) I'll do that right now

[1ucian0]

Sorry for the overlapping, it was part of moving the unroller as a pass :(

[1ucian0]

Since #1441 is closed, I'm closing this PR.

[ajavadia]

I would still like to do what Matthew did in this PR. It provides further speedups to what was already achieved. However, this PR is probably already quite out of sync with master, so might make sense to open a new PR. I'll open an issue.

[mtreinish]

Hmm, it looks like we're still modifying input_dag in the substitute_node_with_dag() even in the non-conditional case. This is causing the failures later when there is a conditional, so simply duplicating the input_dag when there is a conditional (like a00e3a1 ) is not sufficient because the global decomposition dag has already been modified by the time we call copy. We'll need to figure out why/where the input_dag gets modified and guard against that if we plan to use class level attributes for the decomposition_dags.

[1ucian0]

I'm closing this PR because it has conflicts with the current master. Feel free to open a new PR for closing #1729 !

[mtreinish]

@1ucian0 It's unlikely to be feasible while we're still modifying the dag in place. If we move to shared instance for any dag (including the decomposition dags like this commit) this gets really messy since those in place modifications effect the global/shared instance. We have to stop doing that as a first step before this is really something we can consider, especially weighed against the modest performance benefits I was seeing locally (there might be some edge cases I'm missing though)