Constexpr for swap and swap related functions

I. Introduction and Motivation

The Standard Library provides a great collection of algorithms, many of which currently lack constexpr support.
Even a simple constexpr usage requires reimplementing a big bunch of the Standard Library. Consider the simple example:

All the required algorithms already were approved by LEWG in P0202R2, however P0202R2 was
reduced and acceped as P0202R3 because of the CWG 1581.
Now, when CWG 1581 is fixed this paper provides wording for makring with constexpr the algorithms that were not marked by P0202R3 but were in P0202R2.

Adding constexpr to algorithms that use numeric algorithms, searchers, some of the functions in char_traits
and functions that relay on constexpr algorithms (like std::arrays comparison operators) will be covered in separate papers.

II. Impact on the Standard

This proposal is a pure library extension. It proposes changes to
existing headers <utility> and <algorithm> such that the changes do not break existing code
and do not degrade performance. It does not require any changes in the core
language in simple cases of non assembly optimized Standard Library, and it could be implemented in standard C++.

III. Design Decisions

A. <cstring> must not have constexpr additions

B. Assumption that it is possible to implement all the proposed changes without affecting language core, especially [expr.const]

There are many Standard Library implementations nowadays, including
some proprietary. It is impossible to investigate all of them to be 100%
sure that
no performance degradation possible.

This proposal assumes that:

If algorithm uses compiler intrinsics, then those intrinsics could be made constexpr by compiler vendors.

If algorithm uses assembly optimization, then that assembly could be turned into constexpr compiler intrinsic.

If algorithm uses external functions, then those functions could be made inline and marked constexpr or could be replaced with intrinsics.

Modern compilers are good in code optimization, so a decently small amount of algorithms use assembly or intrinsics.

C. Analysis of existing <algorithm> implementations.

Algorithms stable_partition, inplace_merge and stable_sort allocate memory, construct variables using
placement new, use unique_ptr and do other things not acceptable in constexpr expressions. Making those algorithms constexpr
seems to be a hard task that would require a lot of intrinsics. Those algorithms are not marked with constexpr in this wording.

Algorithms shuffle and sample rely upon uniform_int_distribution that has no constexpr functions.
Those algorithms are not marked with constexpr in this wording.

libc++ uses goto in some algorithms, this must be pretty simple to fix without affecting performance.

D. Do not mark ExecutionPolicy&& overloads with constexpr.

It seems that N4687 accidentaly marks some of the ExecutionPolicy&& overloads with constexpr execution policy.
This wording does not mark the ExecutionPolicy&& overloads with constexpr.

Note for editor: All the functions marked with constexpr in previous paragraph of this document must be accordingly marked with constexpr in detailed algorithm description.
For shortness only modifications to "28.6.3 Swap" [alg.swap] are shown in this paper.