Implement LWG-3870 Remove voidify

[frederick-vs-ja]

Fixes #3431.

IIUC static_cast<void*>(p) is OK for most of original uses of _Voidify_iter, since the arguments are generally raw pointers.

The original _Voidify_iter is still valuable for allocate_shared(_for_overwrite) due to fancy pointers, so this PR changes its name to _Voidify_unfancy (with constexpr dropped), moves it to <memory>, and makes it available only when _HAS_CXX20.

The only One remain exception is the use in allocator::construct (removed in C++20), since N4659 [depr.default.allocator]/6 said that cv-qualification is dropped.

Edit: make_shared(_for_overwrite) seemly needs cv-removing mechanisms.

I have no idea how to add test coverage since this only increases hard errors. On the contrary, we need to drop some invalidated test cases.

The test code added in #3396 is invalidated. I have to implement test coverage in another way.

---

There seem some breaking and pre-existing inconsistency in optional, variant, expected, _Variantish, _Movable_box, and _Defaultabox. I'm trying to fix them.

I tried to fix them except for expected. An LWG issue about expected is filed, I'll speculatively implement the proposed resolution. That is LWG-3891 but isn't speculatively implemented here.

---

Now this PR also speculative implements proposed resolutions of 1 LWG issue:

• LWG-3888 Most ranges uninitialized memory algorithms are underconstrained

[StephanTLavavej]

FYI @strega-nil-ms I pushed changes after you approved - all cleanup-level except for a typo bugfix.

[frederick-vs-ja]

LWG-3901 is set to Tentatively NAD, while [mem.poly.allocator.mem]/15 says the plain "by uses-allocator construction" instead of uninitialized_construct_using_allocator, so it seems that polymorphic_allocator::construct is still required to support construction for cv-qualified types.

Should I restore the support?

[StephanTLavavej]

@frederick-vs-ja If I understand the issue correctly, then yes - restoring the support sounds correct. I was about to add this to the final merge batch for 17.7 Preview 1 but I'd rather iterate on this again rather than merge something that has to be corrected later. (Changes will still flow into 17.7 Preview 2 after this.)

[timsong-cpp]

LWG-3901 is set to Tentatively NAD, while [mem.poly.allocator.mem]/15 says the plain "by uses-allocator construction" instead of uninitialized_construct_using_allocator, so it seems that polymorphic_allocator::construct is still required to support construction for cv-qualified types.

If you actually asked that question - about polymorphic_allocator::construct specifically rather than "uses-allocator construction" generally - LWG's answer may well have been different. Certainly mine would be - the allocator requirements do not require construct to support cv-qualified types, and I have no problem with changing polymorphic_allocator::construct.

[strega-nil-ms]

If LWG changes polymorphic_allocator in the future, we can again rip out support for constructing cv-qualified types, I'm not super concerned about it.

[StephanTLavavej]

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

[StephanTLavavej]

Thanks for implementing this major LWG issue!

🐈‍⬛ 🐈‍⬛ 🐈‍⬛