Add support for comparing DEMs up to instruction ordering

[abbrazi]

The current == overload of the DetectorErrorModel only returns true if the DEMs have the same instruction ordering. It is sometimes useful to be able to compare two DEMs for equality when this is not the case, so I implemented an is_equal_up_to_instruction_ordering member function. I opted not to change the == operator because (a) checking for equality up to instruction ordering requires sorting so turns an O(n) op into an O(n log n) op; and (b) it's possible some of the backend simulation code depends on the ordering constraint.

[Strilanc]

Two major problems with this method as currently implemented.

1. Instruction order sometimes matters. In particular, shift_detector instructions change the meaning of later error instructions. If you simply sort the instructions without account for this, you will lose this dependence and break the dem.

2. Not efficient when loops are present. It seems to me that the intent of the method is to basically be graph isomorphism, but that would imply these three dems should all be equal:

error(0.1) D0 D1
shift_detectors 1
error(0.1) D0 D1
shift_detectors 1
error(0.1) D0 D1

and

error(0.1) D0 D1
repeat 2 {
    shift_detectors 1
    error(0.1) D0 D1
}

and

repeat 2 {
    error(0.1) D0 D1
    shift_detectors 1
}
error(0.1) D0 D1

a simple solution would be to first flatten the dem, but that would make the method take far too long when applied to circuits with high repetition counts. There are a few exceptions, but basically all methods in stim are efficient when applied to high-loop-count circuits. This method would also need to meet that bar.

[abbrazi]

Yeah I guess this is a flat world theory :D
It's more interesting than I thought, let me think about it.

[abbrazi]

At this point, you might ask why I don't simply check op_a != op_b before handling the dedicated shift/repeat cases. For repeats, that would result in unexpected failures, i.e., where the the DEMs have the same repeat blocks but they are stored in different orders in the backing blocks arrays. That seems like an implementation detail that should not result in this member function reporting inequality.

[abbrazi]

Have another look at this PR when you get the chance. I updated the ordering-insensitive comparison to handle shifts/repeats efficiently by treating them as structural barriers (must match exactly) and comparing the instruction segments between barriers order-insensitively, so large repeats don’t need to be unrolled.

I still think the most general isomorphic check would be a semantic flatten + canonicalise + sort + compare (where shifts/repeats only matter via their effects), but that’s expensive.

DEM construction seems to be becoming an active area of research, including tools that try to automatically infer detector/logical observable definitions. Utilities like this are useful for validating those approaches against Stim as a golden reference, using an equality notion that’s less strict than == while still being equivalent from the perspective of decoders.

Feel free to reject the PR if you feel these utilities should live elsewhere. I will anyway keep it on my fork.