When determining the install prefix in LLVMConfig.cmake etc resolve
symlinks in CMAKE_CURRENT_LIST_FILE first. The motivation for this is to
support symlinks like `/usr/lib64/cmake/llvm` to
`/usr/lib64/llvm19/lib/cmake/llvm`. This only works correctly if the
paths are relative to the resolved symlink.

It's worth noting that this *mostly* already works out of the box,
because cmake automatically does the symlink resolution when the library
is found via CMAKE_PREFIX_PATH. It just doesn't happen when it's found
via the default prefix path.

Move `FindLibcCommonUtils` from LLVM's CMake module directory to the
shared top-level CMake directory, as the module is intended to be used
from within the source tree rather than the installed LLVM version. This
fixes standalone offload builds after #131205.

Also clear the release notes.

LLD has a bug regarding ordering of static link libraries in the ELF backend, which has been reported as #116669.
CMake 3.31.0 started properly deduplicating static libraries for LLD causing the following linking failure for `libclang-cpp.so` with `-DLLVM_LINK_LLVM_DYLIB=ON`:
```
ld.lld: error: undefined symbol: llvm::omp::getOpenMPClauseName(llvm::omp::Clause)
>>> referenced by OpenMPKinds.cpp
>>>               tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/OpenMPKinds.cpp.o:(clang::getOpenMPSimpleClauseTypeName(llvm::omp::Clause, unsigned int))
>>> referenced by SemaOpenMP.cpp
>>>               tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaOpenMP.cpp.o:(clang::SemaOpenMP::CheckOMPRequiresDecl(clang::SourceLocation, llvm::ArrayRef<clang::OMPClause*>))
>>> referenced by SemaOpenMP.cpp
>>>               tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaOpenMP.cpp.o:(clang::SemaOpenMP::CheckOMPRequiresDecl(clang::SourceLocation, llvm::ArrayRef<clang::OMPClause*>))
>>> referenced 166 more times

[tons more]
```

CMake 3.31 also introduced CMP0179, which builds on CMP0156 and makes the deduplication consistent across platforms.
By coincidence this works around the above LLD deficiency and is the fix that CMake 3.31.1 will implement.
However, the fix is to ignore CMP0156 unless CMP0179 is also enabled, i.e. no more deduplication.
So enable CMP0179 to keep the benefits of deduplication from CMP0156 on LLD and fix the build for CMake 3.31.0.

See: #116669
See: https://gitlab.kitware.com/cmake/cmake/-/issues/26447
Fixes: cb90d5b

Some linkers do not require that libraries are repeated on the command
line. The Apple linker emits warnings when duplicate libraries are
specified, resulting in a wall of warnings.

CMP0156 deduplicates libraries on the command line when the linker
doesn't require them.

This patch enables CMP0156 to quiet the warnings when using a version of
CMake that recognizes it (CMake 3.29 and newer).

The runtimes used to support a build mode called the "Standalone build",
which isn't supported anymore (and hasn't been for a few years).
However, various places in the code still contained stuff whose only
purpose was to support that build mode, and some outdated documentation.
This patch cleans that up (although I probably missed some).

- Remove HandleOutOfTreeLLVM.cmake which isn't referenced anymore
- Remove the LLVM_PATH CMake variable which isn't used anymore
- Update some outdated documentation referencing standalone builds

This makes the message stand out a bit more, which can be helpful to
debug situations where compiler-rt is missing but shouldn't.

CMP0114 was originally set to old to get rid of warnings. However, this
behavior is now set to new by default with the minimum CMake version
that LLVM requires so does not produce any warnings, and setting it
explicitly to old does produce a warning in newer CMake versions. Due to
these reasons, remove this check for now.

Splitting off from removing the CMP0116 check just in case something
breaks.

Partially fixes #83727.

Closes #38383.

This enables parallel custom build commands, which improve compilation
time on Windows with Visual Studio.

Not every toolchain provides and want to use libatomic which is a part
of GCC, some toolchains may opt into using compiler-rt atomic library.