Resolves #64 by implementing WG21-N4861's spaceship customization point objects specified in [cmp.alg].

Note that this is targeted at master, as it doesn't directly interact with #62 which is being developed in feature/spaceship.

• <charconv>
  • Lift _Floating_type_traits into a central header, <type_traits>. It was the only thing using <float.h> here (for FLT_MANT_DIG etc.).
• <type_traits>
  • Include <cstdint> needed by _Floating_type_traits. This is a very small header, "core" compatible, and it's actually surprising that <type_traits> wasn't already dragging it in.
  • Move _Floating_type_traits here. It's functionally unchanged, except that I've eliminated the <float.h> dependency by directly writing out the literal values. I believe that this makes the masks easier to understand, and I've retained the original computations as comments.
  • This also adds _Floating_type_traits<long double>, needed now but not by <charconv>.
  • <charconv> includes <xutility> includes <utility> includes <type_traits>.
  • <compare> includes (in concepts mode) <concepts> includes <type_traits>.
• <xutility>
  • Lift std::ranges::_Choice_t and std::_Implicitly_convertible_to into a central header, <concepts>. Both will remain guarded by __cpp_lib_concepts. _Choice_t is additionally being lifted out to std.
  • <xutility> includes <utility> includes (in concepts mode) <concepts>.
• <compare>
  • Include <bit> for bit_cast. It's a "core" header, although it does drag in <limits>.
  • Possible alternative: We could move _Bit_cast in <xutility> up to <type_traits>, except that it wants memcpy for __CUDACC__ and <type_traits> doesn't include <cstring>. Maybe we could write a raw byte-copying loop?
  • Implement the 6 CPOs.
  • I encountered 2 issues in the Standardese, which @CaseyCarter and I consider to be defects. I filed Spaceship CPO wording in [cmp.alg] needs an overhaul #1374 to track this. They have essentially zero impact for users (the "passing arguments as lvalues" is extremely difficult to observe, and is consistent with more modern Standardese elsewhere; the "block unqualified name lookup" technique is nearly impossible to observe, as I understand it, but should be clearly stated by the Standard.)
  • This "directly" implements the Standardese, using @CaseyCarter's clever _Choice/_Strategy system.
  • This implements strong and weak ordering for floating-point numbers by directly inspecting their representations; I have carefully commented each step, and written comprehensive tests.
• <yvals_core.h>
  • P0768R1 is now fully implemented; remove the "partially implemented" comment.
  • Define the feature-test macro, guarded by __cpp_lib_concepts. Note that __cpp_lib_three_way_comparison is being defined to the lower value 201711L for P0768R1; it will be increased to the larger value 201907L for P1614R2.
• tests/libcxx/expected_results.txt
• tests/libcxx/skipped_tests.txt
• tests/std/tests/VSO_0157762_feature_test_macros/test.cpp
  • Test the feature-test macro.
• tests/std/test.lst
• tests/std/tests/P0768R1_spaceship_cpos/env.lst
• tests/std/tests/P0768R1_spaceship_cpos/test.cpp
  • Add comprehensive tests (requiring the concepts_matrix, but we don't need the strict concepts matrix - I was able to resolve all of the issues with /permissive mode).
  • Verifying "expression-equivalent" is a lot of work! I'm testing the return type, exception specification, and compile-time/run-time behavior. Because there are so many aspects to test, 6 different CPOs, and so many different cases that they activate, I've commented each test with the Standardese bullet point that it's testing.
  • In test_floating(), I've devised a system to test every possible "interesting" pair of floating-point values.