P2165R4: Compatibility Between tuple, pair, And tuple-like Objects

[JMazurkiewicz]

Closes #2917.

[cor3ntin]

LWG issue for the friendship bug with proposed resolution (matching this implementation) https://cplusplus.github.io/LWG/issue3882 (Thanks for pinging me about that!)

[strega-nil-ms]

Pushing a partial review; should finish tmrw

[strega-nil-ms]

This looks great; thanks @JMazurkiewicz!

[StephanTLavavej]

Looks good to me too. I've pushed one last commit to improve the merge with #3483's reformatting, FYI @strega-nil-ms.

[StephanTLavavej]

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

[StephanTLavavej]

I've pushed a commit to address several issues that I found while mirroring:

• Work around VSO-1753916 'C++23 tuple causes x86chk assertion: !"If lookup found RDSymbol before it should find something this time, too", ParseTree.cpp 10376'. This affects _Can_equal_compare_with_tuple_like_v, which uses a pattern that we've never used in the STL before. As it's used only to emit a nice error message for Mandates, I'm simply skipping it for C1XX.
• For tuple_cat(), go back to using typename _Tuple_cat1<_Tuples...>::_Ret instead of auto. This fixes a highly unusual scenario where real world code uses decltype to ask what the result of tuple_cat() of tuple<Abstract> would be. We can mechanically form the return type with the struct machinery, we just can't actually instantiate such a tuple.
• This also requires that we constrain _Tuple_cat1 in C++23 mode, identically to how tuple_cat() is constrained. This allows the entire function to SFINAE away if called with something that isn't tuple-like, such as int.

[StephanTLavavej]

Thanks again, one more step closer to C++23! 😻 🎉 🚀