JIT: Transform SELECT to (folded) bitwise op

[BoyBaykiller]

Fix #123291

1. Add canonicalization of CNS to right: SELECT(x == 0, 1, x > 0) -> SELECT(x != 0, x > 0, 1)
2. Add transform to bitwise op: SELECT(x != 0, x > 0, 1) -> (x == 0) | (x > 0)
3. Add gtFoldAndOrXor to fuse cmps: (x == 0) | (x > 0) -> x >= 0

This overlaps with work that optimizeBools does already. But I think handling it in if-conversion like this is overall better. Perhaps in the future (with the help of this PR and more...) we don't need optimizeBools at all.

I added a general gtFoldAndOrXor to gtFoldExpr to fuse the cmps. I didn't add it to morph (e.g fgOptimizeCommutativeArithmetic) because 1. I am not allowed to call that from if-conversion and 2. my understanding of @EgorBo is that we are moving things like this to gtFoldExpr anyway.

Diffs on XARCH look worse because of https://discord.com/channels/143867839282020352/312132327348240384/1502728076243767439

Note the current costing leads to us frequently rejecting cases, for example:
return x == 3 && y == 3; would be transformed to (x == 3 & y == 3) which optimizeBools doesnt do either, but we get:
Skipping if-conversion that will evaluate RHS unconditionally at costs 8,1 - it only allows up to 7.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[EgorBo]

Diffs on XARCH look worse because of https://discord.com/channels/143867839282020352/312132327348240384/1502728076243767439

this link is not working for me. What is the reason behind bad regressions in both size and perfscore on x64?

[EgorBo]

you need to check side-effects here, otherwise you're potentially removing one

[BoyBaykiller]

I limited it to op->OperIsAnyLocal() || op->OperIsConst() (in my new commit) because I need to do that anyway because of GenTree::Compare. With that check in place, do I still need to check for any side effects?