Addresses #132211  #132754
Part of #95250

Implementation of fmaf16 function for 16-bit inputs.

Summary:
There were a few issues with the first one, leading to some errors and
warnings. Most importantly, this was building on MSVC which isn't
supported.

This reverts commit 221b0117fd21d45098ead779a040a4b939a5c84f.

Some build failures requiring TargetParser and some warnings to clean
up.

Summary:
These tools `amdhsa-loader` and `nvptx-loader` are used to execute unit
tests directly on the GPU. We use this for `libc` and `libcxx` unit
tests as well as general GPU experimentation. It looks like this.

```console
> clang++ main.cpp --target=amdgcn-amd-amdhsa -mcpu=native -flto -lc ./lib/amdgcn-amd-amdhsa/crt1.o
> llvm-gpu-loader a.out
Hello World!
```

Currently these are a part of the `libc` project, but this creates
issues as `libc` itself depends on them to run tests. Right now we get
around this by force-including the `libc` project prior to running the
runtimes build so that this dependency can be built first. We should
instead just make this a simple LLVM tool so it's always available.

This has the effect of installing these by default now instead of just
when `libc` was enabled, but they should be relatively small. Right now
this only supports a 'static' configuration. That is, we locate the CUDA
and HSA dependencies at LLVM compile time. In the future we should be
able to provide this by default using `dlopen` and some API.

I don't know if it's required to reformat all of these names since they
used the `libc` naming convention so I just left it for now.

These changes tracks `dirent.h` for the implementation status of
functions and macros, with respect to the issue (
https://github.com/llvm/llvm-project/issues/122006 ).

These changes tracks `utsname.h` for the implementation status of
functions and macros, with respect to the issue (
https://github.com/llvm/llvm-project/issues/122006 ).

This fleshes out the <link.h> a little more, including the
`struct dl_phdr_info` type and declaring the dl_iterate_phdr
function.  There is only a no-op implementation without tests, as
for the existing dlfcn functions.

See https://lab.llvm.org/buildbot/#/builders/104/builds/18422.

Fixes incorrect logic that went unnoticed until the function was tested
with output and input types that have the same underlying floating-point
format.