(2/2) Add parameter sweep support for Pauli string measurements with readout mitigation

[ddddddanni]

Previous PR is #7435
This PR allow user to run measuring_pauli_strings in sweep mode. In this mode, the function uses parameterized circuits and sweeps parameters for both Pauli measurements and readout benchmarking

[eliottrosenberg]

I tested this on hardware, and it seems to have a bug. For example, compare the last line of the output of this cell to the output of this cell. result and result2 come from the couple of cells above those. Reproduced again futher down in that colab.

[eliottrosenberg]

Ok, I found the difference. If you start with the following circuit:

0: ───────────────────────H───@───H───
                              │
1: ───────────────H───@───H───@───────
                      │
2: ───H───────@───H───@───────────────
              │
3: ───H───@───@───────────────────────
          │
4: ───H───@───────H───@───────────────
                      │
5: ───────────────H───@───H───@───────
                              │
6: ───────────────────────H───@───H───

and then measure X(q(0))*X(q(1))*X(q(2))*X(q(3))*X(q(4))*X(q(5))*X(q(6)), the sweep version gives you

0: ───────────────────────H───@───H───PhX(phi0/2 - 1/2)^theta0───M('m')───
                              │                                  │
1: ───────────────H───@───H───@───────PhX(phi1/2 - 1/2)^theta1───M────────
                      │                                          │
2: ───H───────@───H───@───────────────PhX(phi2/2 - 1/2)^theta2───M────────
              │                                                  │
3: ───H───@───@───────────────────────PhX(phi3/2 - 1/2)^theta3───M────────
          │                                                      │
4: ───H───@───────H───@───────────────PhX(phi4/2 - 1/2)^theta4───M────────
                      │                                          │
5: ───────────────H───@───H───@───────PhX(phi5/2 - 1/2)^theta5───M────────
                              │                                  │
6: ───────────────────────H───@───H───PhX(phi6/2 - 1/2)^theta6───M────────

with the basis change all in the same moment, whereas in the batch version, you get

0: ───────────────────────────────H───────────@───H───────────Ry(-0.5π)───M('m')───
                                              │                           │
1: ───────────────H───────────@───H───────────@───Ry(-0.5π)───────────────M────────
                              │                                           │
2: ───H───────@───H───────────@───Ry(-0.5π)───────────────────────────────M────────
              │                                                           │
3: ───H───@───@───Ry(-0.5π)───────────────────────────────────────────────M────────
          │                                                               │
4: ───H───@───────H───────────@───Ry(-0.5π)───────────────────────────────M────────
                              │                                           │
5: ───────────────H───────────@───H───────────@───Ry(-0.5π)───────────────M────────
                                              │                           │
6: ───────────────────────────────H───────────@───H───────────Ry(-0.5π)───M────────

with the basis change done as early as possible. In this case, you get a higher-fidelity result with the basis change done as early as possible because you are insensitive to the dephasing that happens between the final basis change gate and the measurement, but that may not always be the intended behavior. Maybe we could add an insert_strategy argument so that users have the choice of whether to do the basis change all in the same penultimate moment or as early as possible.