SCEV currently tries to prove implications of `x pred y` by also trying to imply `~y pred ~x`. This is expensive in terms of compile-time (in fact, the vast majority of isImpliedCond compile-time is spent here) and generally not fruitful. The issue is that this also swaps the operands and thus breaks canonical ordering. If originally we were trying to prove an implication like `X > C1 => Y > C2`, then we'll now try to prove `X > C1 => C3 > ~Y`, which will not work.

The only real case where we can get some use out of this transform is if the original conditions were in the form `X > C1 => Y < C2`, were then swapped to `X > C1 => C2 > Y` and are then swapped again here to `X > C1 => ~Y > C3`.

As such, handle this at a higher level, where we are doing the swapping in the first place. There's four different ways that we can line up a predicate and a swapped predicate, so we use some heuristics to pick some profitable way.

Because we now try this transform at a higher level (isImpliedCondOperands rather than isImpliedCondOperandsHelper), we can also prove additional facts. Of the added tests, one was proven previously while the other wasn't.