Unitary Synthesis of ChoiMixTableau for Diagonalisation

[willsimmons1465]

I have copied this across from refactor/pauligraph where these changes are useful for making ChoiMixTableau a central representation for diagonalisation. This PR changes the following:

• PauliGadget construction code largely moved into Diagonalisation folder (viewing the Clifford component as a trivial diagonalisation of one or two Pauli strings) or into PauliExpBoxes.cpp for building boxes.
• cm_tableau_to_circuit now takes a second argument to switch between exact synthesis, which may use initialisations, discarding, collapses, etc. to exactly construct the channel corresponding to the ChoiMixTableau, or unitary synthesis, which synthesises a unitary channel whose stabilizer group contains at least all the rows of the input tableau (possibly supplemented with Zs on unused inputs intended to be initialised or unused outputs intended to be postselected).
• Fixes a bug in ChoiMixTableau where terms on the input segment are inconsistently transposed.
• Adds all remaining Clifford OpTypes into gate handling for SymplecticTableau and UnitaryTableau.
• Better semantics tests for tableaus to ensure actual correctness instead of just internal consistency.

Making this a draft PR for now to look for some feedback on the changes to the code structure. Some of the code could really do with a strong tidying up because it is getting rather incomprehensible, and I suspect I will still need to bump coverage stats.

[willsimmons1465]

I've made the synthesis code much cleaner and broken into simpler stages. The unitary synthesis of ChoiMixTableau does not currently get used in user-facing features, but will be useful in the upcoming PauliGraph refactor.

This PR also refactors the Pauli gadget synthesis code to always apply some diagonalisation method to reduce it completely to a single Rz gate. The only differences this should give in the end circuits occurs during pairwise synthesis: previously, the synthesis would only reduce the overlap to a single qubit and then would synthesise each gadget separately (and always using CXConfigType::Snake rather than the CXConfigType given to the method), which would mean Clifford gates occur between the core rotations, trapping them from being considered for peephole optimisation (relevant 2qb gates would not be able to commute through the core rotations). Now, the gadgets are completely reduced to either an Rz and Rx on the same qubit or simultaneous Rzs (using a consistent CXConfigType for the reductions). In theory, this uses the same number of 2qb gates for synthesis and more of them are exposed for peephole optimisation with the environment the gadgets appear in, so we would heuristically expect better performance, but the different arrangement of gates makes this inconsistent and hard to predict.

[cqc-alec]

Quite a tour de force! I've just left a few comments.

[cqc-alec]

I think there was just one doxygen comment missed (which I've left unresolved); otherwise looks good!

[cqc-alec]

Thanks!