Zero-diff part of "Use SSA-based ComputeRange"

[EgorBo]

Extracted from #112824 for simpler code review

[dotnet-policy-service]

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

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

[EgorBo]

@jakobbotsch @AndyAyersMS @dotnet/jit-contrib PTAL, zero-diff change. Just preparations for using RangeCheck in assertprop (in #112824):

1. Hid all maps under lazy-init getters (these maps are cleaned on every GetRange call, so the state is not shareable between phases).
2. RangeCheck becomes a singleton instance - this helps to reduce TP impact and allocations when it's called from Assertprop
3. Removed verbose SSA validation - it's quite ad-hoc and messy, also, it's an additional state that I had to reset between phases. RangeCheck used to be the last phase to use SSA, but it's not the case today so if we need it, we have to come up with some generic SSA validation and use it everywhere.
4. Propagated block into various optAssertionProp_* that I'll need.

CI failures are unrelated.

[AndyAyersMS]

I guess we're trying to economize by keeping the collection backbones around once we've allocated them.

Could we make it clearer which parts of the range check state are durable and which parts are not? Eg split out the more transient parts into a caller-supplied struct or something?

Or make it harder to accidentally call into the wrong part of range check?

[AndyAyersMS]

Should this now be private? Ditto for some of the other helpers.

[AndyAyersMS]

This part reads a bit oddly -- if we don't have a search path we create one and then immediately remove everything in it? Maybe EnsureEmpty? which first checks if the thing is allocated?