Convert pubs to equivalent pubs that are rzz-valid

[yaelbh]

Opening a fresh blank issue for an approach to solving #2032, see related discussion also in #2072.

User circuits may contain RZZ gates with invalid angles (i.e., negative or greater than pi/2). There are two types of usages of RZZ:

1. Numeric - for example an RZZ gate with angle of -1.3 radians on qubits 4 and 2: rzz(-1.3, 4, 2). We take care of these gates when transpiling for IBM backends, using the FoldRzzAngle pass.
2. Parametrized - the angle is specified by a parameter or a parameter expression, for example rzz(p, 4, 2), rzz(p1 + p2, 3, 4). The parameters are later instantiated with values, which may result in invalid angles. This issue is about this parametrized case.

#2032 focuses on invalid pubs resulting from transpilation. Another important and frequent use case relates to the original pub, as specified by the user, even before transpilation: the pub can contain many parameter sets, making it impossible for the user to detect and fix faulty parameter sets. This issue applies to both scenarios.

We will make pubs valid by following the construction of the FoldRzzAngle pass. We will add to the circuit new rz and rx gates, and extra parameters for the new gates and for a modified RZZ gate. We will append values of the new parameters to the parameter values.

An interesting question is whether to implement this procedure by writing a function that receives valid pubs and outputs invalid pubs; or by writing a transpiler pass, and accompanying it with a function that modifies the parameter values. A function is a cleaner interface and easier to opt-in. It may however mess up with dynamical decoupling. I'm interested to hear opinions about these two options (@nkanazawa1989 , @wshanks, @ihincks, @jyu00, @mtreinish, @jakelishman).

A bit more clarification about dynamical decoupling: the user can run the function before or after transpilation. If before then we can get the #2032 surprise. If after then the circuit is altered after dynamical decoupling.

Finally, a smaller things to think of: Automatic addition of new parameters may cause name collision with user parameters.

[wshanks]

Incompatibility with dynamical decoupling is a problem with the single function solution. Combining a transpiler pass with a function to expand the parameter values makes sense to me. There could be a second function that just runs the transpiler pass and calls the parameter value function if we wanted to provide the single function option as well. I don't think we would want this transpiler pass to run by default. Maybe the way that the user enables it could also allow for a rule for naming the parameters to avoid conflicts with the circuit's other parameters.

How the function would match the added parameters to their values. Would it iterate through the circuit to find rzz gates and look forward and back to find the parameterized rz and rx gates that it could assume are their for it to use?

[yaelbh]

I started to write the non-pass version in #2126. There, I use the fact that it's not a pass to construct the new parameters during circuit modification. This allows to add extra gates and parameters only if it's really necessary. For example, the circuit will remain unchanged if all the rzz angles evaluate to valid values.