Improve IntegralRange::ForCastOutput in assertion prop

[MihaZupan]

https://gist.github.com/MihuBot/dea35dcc7a03aa6982f9cb187965a762

The diff in BigInteger is for a pattern like this

int Foo(ulong x) => BitOperations.LeadingZeroCount(x) / 8

where the JIT didn't see BitOperations.LeadingZeroCount as non-negative since it's implemented as (int)Lzcnt.X64.LeadingZeroCount(value).

E.g.

-       mov      edx, edi
-       sar      edx, 31
-       and      edx, 7
-       add      edi, edx
-       sar      edi, 3
+       shr      edi, 3

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refines the JIT’s integral range analysis for certain non-overflowing casts by allowing IntegralRange::ForCastOutput to return a tighter range derived from the cast operand when it is provably within the cast’s default output range. This improves downstream assertion/range reasoning and can enable simpler codegen when the JIT can preserve non-negativity (and other range constraints) through casts.

Changes:

• Compute the cast’s default output range (typeRange) for the relevant non-overflowing cast cases.
• In non-MinOpts, compute the operand’s range and, when it’s contained within typeRange, return the tighter operandRange instead of the broader default.