Update merging of Conditional block in greedy_pauli_optimisation

[sjdilkes]

Description

The circuit:

comp.add_op<unsigned>(OpType::Rx, 1.0246, {0});
comp.add_conditional_gate<unsigned>(OpType::Ry, {-0.25}, {1}, {0}, 0);
comp.add_conditional_gate<unsigned>(OpType::CZ, {}, {1, 0}, {0}, 0);

Is incorrectly optimised by greedy_pauli_optimisation. This is because the conditional Ry gate is considered commuting with the Rx gate, and then the conditional CZ gate is merged into the same "block" as the Ry gate. This block is incorrectly considered as commuting with the Rx gate, and later at construction the result is that the CZ gate is commuted ahead of the Rx gate, producing an incorrect circuit.

The fix I've added is to only allowing commuting of non-conditional gates forward. This is because we can only incorrectly produce non-commuting blocks by merging gates into a block, which only happens with conditional cases.

This leads to a test regression in this circuit:

circ.add_op<unsigned>(cond1, {0, 0, 1});
circ.add_op<unsigned>(OpType::Rz, 0.3, {0});
circ.add_op<unsigned>(cond2, {0, 0, 1});
circ.add_conditional_gate<unsigned>(OpType::CX, {}, {0, 1}, {0}, 0);
circ.add_conditional_gate<unsigned>(OpType::CX, {}, {0, 1}, {0}, 0);
circ.add_op<unsigned>(OpType::Rz, -0.3, {0});

where the Rotation gates are no longer correctly cancelled (but everything else is).

My opinion is that safe forward-merging of conditional blocks will take serious code changes, and that cases where identical Pauli exponentials are not merged through conditional circuits are a) unlikely to be common in circuits, and b) the Pauli exponentials will still be "close" in the PauliGraph, meaning regularly they may just appear as adjacent rotations in a final circuit that can be compiled out using a pass like RemoveRedundancies.

Related issues

Please mention any github issues addressed by this PR.

Checklist

• I have performed a self-review of my code.
• I have commented hard-to-understand parts of my code.
• I have made corresponding changes to the public API documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have updated the changelog with any user-facing changes.