Upgrade to C++20

[Morwenn]

The first C++20 have already started appearing a few months ago. I'm creating this issue to make sure that I can track the smaller things that may make it into the standard and provide potential improvements to cpp-sort as they get incorporated into the standard draft. Here is the list (strikethrough text means that the feature won't/can't be used):

• Some parts of concepts have been merged into the C++20 draft, which may be used to properly define sorters, and to partly implement issues Handle sentinel parameters #20, Error messages are unreadable #28 and Counted iterators #43.
• The Ranges TS has been merged in C++20, see Handling the Ranges TS once merged into the standard #130 for how to handle it and the related facilities specifically.
• Standard library concepts brings <concepts> to the standard library which can be used to constrain sorting functions.
• std::identity is an almost exact replacement for cppsort::utility::identity.
• operator<=> and std::compare_3way can be used to simplify the few classes where we implement relational operators, which should mainly be a few iterator classes (I will have to check whether we also have classes that implement comparison only).
• operator<=> will otherwise surely interact with the library in some ways we can take advantage of, not sure how, but we will definitively need to track that (corresponding issue: Three-way comparison #145).
• constexpr algorithms might be of use for What about constexpr? #58. Since we reimplement many standard library algorithms, I hope that most of them won't have to rely on intrinsics. All the other constexpr improvements might help to implement the remaining pieces (see What about constexpr? #58 for additional details).
• Replace detail::memcpy_cast by std::bit_cast.
• Replace detail::log2 by std::log2p1 and detail::hyperfloor by std::floor2 (are they compatible when x == 0?).
• I'm pretty sure that we already reimplement some of the other proposed bit functions, check whether it is the case and replace appropriately.
• Down with typename! will be fun: remove plenty of typename everywhere :D
• We currently use std::tuple to store class members when we know that some of them might be empty to hopefully benefit from an EBCO-optimized implementation. Using [[no_unique_address]] instead would allow to have readable names while getting rid of the <tuple> dependency in a few places, and it should even give shallower calls stacks and fewer template instantiations.
• Designated initializers could be used to create a cppsort::options object to pass "named" parameters to cppsort::sort and maybe to the sorters, but there will likely be subtle issues which make the feature not worth having.
• We already ship an implementation of remove_cvref to replace std::decay when it is overkill. We can replace it with the standard library version once it is available.
• Replace our implementation of is_bounded_array with std::is_bounded_array.
• The testsuite should include tests for subrange instead of the currently used span-like class since they are roughly equivalent (yes, our span isn't equivalent to the std:: one).
• std::get_temporary_buffer is dead, replace it by an equivalent hand-rolled solution.
• std::ssize can be used instead of std::size when we expect a signed value (e.g. when passing the size to a difference_type variable). (mstd::distance is the preferred solution there)
• Check whether small features like class template argument deduction for aggregates and alias templates, constinit, conditionally trivial special member functions, can make some parts of the libraries lighter, safer, more idiomatic, etc.
• std::format is a welcome addition for the tooling, if not for the main library.
• The standard library headers should be importable as legacy header units, import those instead of using #include if possible.
• It might also be the right time to start thinking about modularizing the library.
• ska_sort needs dedicated support for char8_t.
• std::bind_front might replace some lambdas and alleviate the potential capturing-lambda-in-template bloat.
• std::midpoint can be used here and there to make the code more expressive, and obviously safe (this function actually only works for arithmetic and pointer types, not iterators).

While some of these changes are mere implementation details which improve only the quality of the implementation, and sometimes its correctness or performance, a few of them also impact the documentation and the examples:

• Mention that when std::identity is available, cppsort::utility::identity is merely an alias for it. (not a great idea, we don't alias and support them side-by-side in 1.x.y)
• Stateless lambdas are now default-constructible, which might trigger a few space optimizations, but might also make more things convertible to function pointers here and there. Investigate & document.

Also free lunch time for more implicit moves, we don't have anything to do, just enjoy the free additional moves here and there :D