Support for memcpy with equal source and destination

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

The BZ#31055 [1] requests a guarantee that memcpy with equal source and
destination is well defined on glibc, since both gcc and clang already
emits code with this assumption [2] [3].  There is a WIP document [4] to
proper extend this requirement for C standard, with some extra requirement
(such as allowing NULL inputs).

The GCC bug report [5] have further information on why GCC developers thing
this is a reasonable assumption, most related to the codgen cost of adding
either the extra compare to correctly call mempcy or just change the call
to memmmove.

From glibc standpoint, as far I could check there is no implementation that
prevents it (although I am not sure for all of them for all input sizes).
The memcpy with equal source and destination will still triggers compiler
warnings due the restrict issues, but it should not matter to compiler 
auto-generated libcalls.

Another solution would be to provide an alternative symbol, similar to 
__memcmpeq, meant to be used by the compiler to libcall optimizations.
However, __memcmpeq did not have any adoption so far [6] [7].

If we adopt this constraint, I think it would require to add some testing
besides the manual documentation.  Some arch maintainers would also like
to check their implementation to add an early bailout optimization. I also
presume that the fortify builtins already handle it correctly.

I am not sure about other libc implementation, at least Musl seems unlikely
to provide such guarantee.

Thoughts?

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=31055
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=7758cb4b53e8a33642709402ce582f769eb9fd18;hp=6ce952188ab39e303e4f63e474b5cba83b5b12fd
[3] https://reviews.llvm.org/D86993
[4] https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UCPyZOTLsnRfR6UleD1F8/edit
[5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[6] https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596881.html
[7] https://reviews.llvm.org/D127461