[version.syn] FTMs for freestanding features should be freestanding

[Mick235711]

LWG4189 (accepted in Hagenberg via #7660) added nearly the entire <ranges> header to freestanding. However, the only feature-test macro being added to freestanding is __cpp_lib_ranges_cache_latest, which seems weird, since views::enumerate is also added to freestanding following the blanket comment strategy, but its feature-test macro remains not in freestanding.
I don't think views::enumerate and views::cache_latest should be treated differently here, so this PR tries to sync the status of their FTMs.

Another issue is reserve_hint (#7698). The paper itself does not state clearly whether __cpp_lib_ranges_reserve_hint should be in freestanding or not, but given that ranges::reserve_hint itself is in freestanding, I think the FTM should also be in too.

[frederick-vs-ja]

See also LWG4126. As there's already an accepted LWG issue, I want the changes here to be handled editorially.

[Mick235711]

I think it's more consistent to ensure feature-test macros for fully freestanding features are also freestanding.

If that is the case, then maybe all of __cpp_lib_ranges_* FTMs should be marked as freestanding? Currently, the ones representing new range algorithms are not marked, but these algorithms themselves are already freestanding given that [algorithm.syn] does have // mostly freestanding attached as the result of the acceptance of P2976 at Hagenberg (#7706).

P2976 does not discuss FTM changes much, only adding __cpp_lib_freestanding_{execution,random}. I'm not closely following the discussion of that paper enough to understand if this is a conscious design decision or simply forgetting to update the comments on the __cpp_lib_ranges_* FTMs (since normal algorithms don't have FTMs, only range algorithms had). I looked into the notes of two times that P2976 was reviewed, in Tokyo (notes) and in Hagenberg (notes), and ranges algorithms doesn't seem to be discussed at all. Hopefully, this still counts as editorial?

[frederick-vs-ja]

If that is the case, then maybe all of __cpp_lib_ranges_* FTMs should be marked as freestanding?

Probably yes except for __cpp_lib_ranges_generate_random. It's unclear to me whether ranges::generate_random is suitable for freestanding. And even if so, an LWG issue is necessary to make it freestanding.

IIUC that the following FTMs should also be freestanding. Some of them should have been so when adopting LWG4126, but I overlooked them.

• __cpp_lib_array_constexpr
• __cpp_lib_aligned_accessor
• __cpp_lib_clamp
• __cpp_lib_constexpr_numeric
• __cpp_lib_function_ref
• __cpp_lib_gcd_lcm
• __cpp_lib_integer_comparison_functions
• __cpp_lib_ranges_contains
• __cpp_lib_ranges_find_last
• __cpp_lib_ranges_fold
• __cpp_lib_ranges_iota
• __cpp_lib_ranges_starts_ends_with
• __cpp_lib_robust_nonmodifying_seq_ops
• __cpp_lib_sample
• __cpp_lib_saturation_arithmetic

is_sufficiently_aligned (with __cpp_lib_is_sufficiently_aligned) is in a weird state. P2897R7 indicated that is_sufficiently_aligned should be freestanding, but the merged wording didn't say so. Not sure where there should be an LWG issue.

[Mick235711]

Changes done.
I included making is_sufficiently_aligned and its FTM in freestanding for now, since I think it is an omission that should be editorially synced to match the original intent of the paper; if it is decided that this should be a separate LWG issue the change can be easily split out.