This is the first step in preparation for:
https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450

Summary:
This is a massive patch because it reworks the entire build and
everything that depends on it. This is not split up because various bots
would fail otherwise. I will attempt to describe the necessary changes
here.

This patch completely reworks how the GPU build is built and targeted.
Previously, we used a standard runtimes build and handled both NVPTX and
AMDGPU in a single build via multi-targeting. This added a lot of
divergence in the build system and prevented us from doing various
things like building for the CPU / GPU at the same time, or exporting
the startup libraries or running tests without a full rebuild.

The new appraoch is to handle the GPU builds as strict cross-compiling
runtimes. The first step required
https://github.com/llvm/llvm-project/pull/81557 to allow the `LIBC`
target to build for the GPU without touching the other targets. This
means that the GPU uses all the same handling as the other builds in
`libc`.

The new expected way to build the GPU libc is with
`LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`.

The second step was reworking how we generated the embedded GPU library
by moving it into the library install step. Where we previously had one
`libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This
patch includes the necessary clang / OpenMP changes to make that not
break the bots when this lands.

We unfortunately still require that the NVPTX target has an `internal`
target for tests. This is because the NVPTX target needs to do LTO for
the provided version (The offloading toolchain can handle it) but cannot
use it for the native toolchain which is used for making tests.

This approach is vastly superior in every way, allowing us to treat the
GPU as a standard cross-compiling target. We can now install the GPU
utilities to do things like use the offload tests and other fun things.

Some certain utilities need to be built with 
`--target=${LLVM_HOST_TRIPLE}` as well. I think this is a fine
workaround as we
will always assume that the GPU `libc` is a cross-build with a
functioning host.

Depends on https://github.com/llvm/llvm-project/pull/81557

Having libc_errno outside of the namespace causes versioning issues when
trying to link the tests against LLVM-libc. Most of this patch is just
moving libc_errno inside the namespace in tests. This isn't necessary in
the function implementations since those are already inside the
namespace.

The previous patches added the necessary support for global constructors
used to register tests. This patch enables the AMDGPU target to build
and run the unit tests on the GPU. Currently this only tests the `ctype`
tests, but adding more should be straightforward from here on.

Reviewed By: sivachandra

Differential Revision: https://reviews.llvm.org/D149517

Previously, only those unit tests which belonged to a suite were run as
part of libc-unit-tests. It meant that unit tests not part of any suite
were not being tested. This change makes all unit tests run as part of
libc-unit-tests. The convenience function to add a libc unit test suite
has been removed and add_custom_target is used in its place. One of the
bit-rotting test has along been fixed. Math exhaustive and differential
tests are skipped under full build.

Reviewed By: michaelrj

Differential Revision: https://reviews.llvm.org/D148784

This part of the effort to make all test related pieces into the `test`
directory. This helps is excluding test related pieces in a straight
forward manner if LLVM_INCLUDE_TESTS is OFF. Future patches will also move
the MPFR wrapper and testutils into the 'test' directory.

With modern architectures having a thread pointer and language supporting
thread locals, there is no reason to use a function intermediary to access
the thread local errno value.

The entrypoint corresponding to errno has been replaced with an object
library as there is no formal entrypoint for errno anymore.

Reviewed By: jeffbailey, michaelrj

Differential Revision: https://reviews.llvm.org/D120920

In mixed mode builds, we should not be including errno as part of
LLVM libc - errno from another library (or the system library) should be
used. But, other entrypoints which use errno list LLVM libc's errno as a
dep ta satisfy the full build mode. So, we add a dummy errno
implementation with empty files to make both mixed mode and full build
mode happy.