Move <ranges> and <format> into C++20

[CaseyCarter]

and add 128-bit signed and unsigned integer-class types to be the difference of iota_view<64-bits>.

• In <yvals_core.h>, don't require _HAS_CXX23 to define __cpp_lib_format and __cpp_lib_ranges. Change the feature-test macro test consistently.

• Change env.lst for all tests that touch <ranges> and <format> to use 20 matrices instead of latest.

• Don't use the span constructor added to C++23 by WG21-P1989 in P0896R4_views_split, which now must run in C++20 mode where that constructor is unavailable.

Fixes #1814.

For ease of review there are two commits: the first is just the 23-to-20 changes, and the second adds the integer-class type.

Internal-only changes

Reminder for MSVC-internal tasks (the "add new internal header" things):

• Notify vctowner that we're adding a new internal header __msvc_int128.hpp.
• Run src/vctools/crt/lkgsync/updatelkgmanifest.cmd.
• Edit src/SetupPackages/swix/crt.headers/files.base.swr.
• Edit src/vctools/crt/copy_crt/copy_crt.nativeproj.
• Edit src/qa/VC/FE/compiler/tests/cxx/modules/dependency-scanning/header-units/deps.cpp.
• Edit src/qa/VC/FE/compiler/tests/cxx/modules/dependency-scanning/header-units/stl-header-units.dat.

[AlexGuteniev]

If there's a need to introduce 128-bit integers, maybe put them into an "extended" header, not "internal" header, and address DevCom-879048 ?

[AlexGuteniev]

If there's an issue with iota_view<64-bits> which is resolved be 128-bit integer, what about using this new integer with iota_view<128-bits> 🤔 ?

[AlexGuteniev]

Can/should this new big integer be merged with big integer from #2366 ?

[StephanTLavavej]

@AlexGuteniev #2518 (comment)

Can/should this new big integer be merged with big integer from #2366 ?

Good question - but no, _Big_integer_flt is very big (stores many bits), uses 32-bit elements, and is paradoxically very small - it supports an extremely limited set of operations compared to what Casey has implemented here. There's really no commonality.

[miscco]

Some nits, feel free to ignore all the debug codegen stuff. We can do this later when time is not pressing

[CaseyCarter]

If there's a need to introduce 128-bit integers, maybe put them into an "extended" header, not "internal" header, and address DevCom-879048 ?

The type exists and is available if people want to use it, albeit with the hard-to-spell name iter_difference_t<ranges::iterator_t<ranges::iota_view<long long>>>. I don't think we want to advertise it as the type those folks want, at least not until we've addressed the performance concerns and stressed it for a while to make sure the bugs are out.

If there's an issue with iota_view<64-bits> which is resolved be 128-bit integer, what about using this new integer with iota_view<128-bits> 🤔 ?

The goal of the change isn't to require the library to provide arbitrary-precision integers, its to ensure that people don't stumble into UB using iota_view<long long> and its iterators normally, e.g., ranges::distance(views::iota(numeric_limits<long long>::min(), numeric_limits<long long>::max())). See WG21-P1522 for gory detail.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[CaseyCarter]

Thank me for pushing to get this done a week ahead of my planned schedule, and extra-special thanks to @StephanTLavavej for the real-time code review to make it possible! ❤️

(Historical note: I bypassed branch policy - as discussed with STL over the weekend - to merge this with only one maintainer review due to time crunch. We did have a few very good contributor reviews to add confidence.)