Add check for graph validity before commuting conditional gates in squashing passes

[cqc-alec]

Fixes #1324 .
Fixes #1357 .

I was a bit concerned about the performance impact of this but it increases the running time of the tket tests by only about 1% so I think it's OK. (If it does turn out to be a problem, an alternative would be never to commute these gates, but that would give poorer results -- or somehow to find a cheaper way to do the check.)

[lmondada]

Thanks @cqc-alec!

For future reference, I'll mention here that an alternative that was discussed was to forbid the commutation of classically controlled gates, when one of the bits it is controlled on is i) overwritten by a future measurement (when squashing forward), or ii) is used as control for another operation in the past (when squashing backward).

This would be a sufficient condition to ensure correctness and would be very quick to check. It would still do the right thing for a (the most common?) subset of conditionally controlled gates, so might be a good half-way solution if the full check implemented here becomes too expensive.