Bounds checks: make MergeEdgeAssertions more precise

[EgorBo]

This PR elides bounds checks in #113054 (closes #113054)

It turned out that MergeEdgeAssertions used to depend on order of assertions when it was tightening them so the behavior was different for tightening BinOpArray vs Constant (whoever comes first). Now the logic is more sophisticated and doesn't depend on the order of assertions.

[Copilot]

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

[EgorBo]

PTAL @AndyAyersMS @jakobbotsch @dotnet/jit-contrib Diffs

[MihaZupan]

A bunch of hits on Regex: https://gist.github.com/MihuBot/f104c03eb53bf3c2f724d70a520636d1

[AndyAyersMS]

LGTM.

This method is getting pretty large/unwieldy, you might think about how it could be broken up.

I wonder if we have order dependencies elsewhere in AP, often we stop at the first assertion we find that tells us anything.

Would also be interesting to have a stress mode or something that just reverse the order of assertion iteration. If this is not zero diff then we have things to explore.

[EgorBo]

Yep, I plan a massive clean up (zero-diff) here and will inject stress modes.

In this case diffs appeared because of the order e.g.:

if X > 100 appears before "X > arrLen" we used to take "X > 100" and ignored "X > arrLen"
if X > arrLen appears before "X >100" then we used to intentionally ignore "X > 100" with "we think arrLen is better" comment

Now we always prefer "X > arrLen" (but only if the 'preferredBound' was set) - we can play with this heuristic and e.g. accept 0/1 constants, but the diffs are mixed

also, a few missing rules that I added