Issue in `kontrol merge-nodes` when a simplification only applies in one branch

kontrol merge-nodes can run into an issue where one branch simplifies an expression and the other doesn't, which causes problems when the two branches are merged. For example, the following happens when trying to use it for the test in PR #162:

1. One of the side conditions C in our configuration contains the subexpression X modInt 2 ==Int 0.
2. We branch on the condition X /Int 2 ==Int 0.
3. In the branch where X /Int 2 ==Int 0, X modInt 2 ==Int 0 can be simplified to X ==Int 0. This turns C into a different side condition C'.
4. In the branch where X /Int 2 =/=Int 0, the simplification doesn't apply, so it remains as C.
5. As a result, when we merge the two nodes, instead of getting C #And ( ( X /Int 2 =/=Int 0 andBool B ) orBool ( X /Int 2 ==Int 0 andBool B' ) ) (where B and B' are the constraints that are different between the two branches) we instead get ( ( X /Int 2 =/=Int 0 andBool B andBool C ) orBool ( X /Int 2 ==Int 0 andBool B' andBool C' ) ).

Because this can happen when C is alread a merged expression like (P andBool Q) orBool (notBool P andBool Q'), this can quickly compound over multiple applications of merge-nodes and grow into a large unreadable expression with multiple nested andBool and orBool operators.

What can we do about this?

• While we can write a lemma to turn ( ( X /Int 2 =/=Int 0 andBool B andBool C ) orBool ( X /Int 2 ==Int 0 andBool B' andBool C' ) ) back into C #And ( ( X /Int 2 =/=Int 0 andBool B ) orBool ( X /Int 2 ==Int 0 andBool B' ) ), this lemma is both very complex and very non-generalizable (we would need to write a different lemma for every case). So this approach doesn't seem ideal.
• If we were able to specify what we want our merged node to look like, Kontrol should be able to determine that it subsumes both of the individual nodes being merged. This is similar to a loop invariant, and if we implement a way to specify loop invariants as annotations in the Solidity code, that functionality can probably also be used for this.

Start by inspecting the implementation and behavior of kontrol merge-nodes, then reproduce the simplification mismatch described for the test in PR #162. Done should mean that merging branches with different simplification results preserves a shared side condition, or provides a general way to specify the intended merged node or invariant.