The LLVM-customized GTest has a dependency on LLVM to support
`llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes
use the LLVMSupport from the bootstrapping LLVM build. The problem is
that the boostrapping compiler and the runtimes target can diverge in
their ABI, even in the runtimes default build. For instance, Clang is
built using gcc which uses libstdc++, but the runtimes is built by Clang
which can be configured to use libcxx by default. Altough it does not
use gcc, this issue has caused
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to
break, and is still (again?) broken.

This patch makes the runtimes' GTest independent from LLVMSupport so we
do not link any runtimes component with LLVM components.

Runtime projects that use GTest unittests:
 * flang-rt
 * libc
* compiler-rt: Adds `gtest-all.cpp` with
[GTEST_NO_LLVM_SUPPORT=1](https://github.com/llvm/llvm-project/blob/f801b6f67ea896d6e4d2de38bce9a79689ceb254/compiler-rt/CMakeLists.txt#L723)
to each unittest without using `llvm_gtest`. Not touched by this PR.
* openmp: Handled by #159416. Not touched for now by this PR to avoid
conflict.

The current state of this PR tries to reuse
https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt
as much as possible, altough personally I would prefer to make it use
"modern CMake" style. third-party/unittest/CMakeLists.txt will detect
whether it is used in runtimes build and adjaust accordingly. It creates
a different target for LLVM (`llvm_gtest`, NFCI) and another one for the
runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest`
for both since `llvm_gtest` is imported using `find_package(LLVM)` if
configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to
select between the two. `default_gtest` could also be used for openmp
which also supports standalone and
[LLVM_ENABLE_PROJECTS](https://github.com/llvm/llvm-project/pull/152189)
build mode.

This implements the parts of
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3457.htm which were
adopted at the recent meeting in Brno.

Clang already implemented `__COUNTER__`, but needed some changes for
conformance. Specifically, we now diagnose when the macro is expanded
more than 2147483647 times. Additionally, we now give the expected
extension and pre-compat warnings for the feature.

To support testing the limits, this also adds a -cc1-only option,
`-finitial-counter-value=`, which lets you specify the initial value the
`__COUNTER__` macro should expand to.

This PR adds the code of Boost.Math as of version 1.89 into the
third-party directory, as discussed in a recent RFC [1].

The goal is for this code to be used as a back-end for the C++17
Math Special Functions.

As explained in third-paty/README.md, this code is cleared for
usage inside libc++ for the Math Special functions, however
the LLVM Foundation should be consulted before using this
code anywhere else in the LLVM project, due to the fact
that it is under the Boost Software License (as opposed
to the usual LLVM license). See the RFC [1] for more details.

[1]: https://discourse.llvm.org/t/rfc-libc-taking-a-dependency-on-boost-math-for-the-c-17-math-special-functions

A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b

However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:

`if (${CMAKE_SYSTEM_NAME}  MATCHES "AIX")`
which becomes:
`if (AIX  MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`

You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.

These changes allow LLVM and Clang to be built with Clang targeting
Arm64EC using the MSVC linker.

Built with these options:
```
-DLLVM_ENABLE_PROJECTS="clang"
-DLLVM_HOST_TRIPLE=arm64ec-pc-windows-msvc
-DCMAKE_C_COMPILER=clang-cl.exe
-DCMAKE_C_COMPILER_TARGET=arm64ec-pc-windows-msvc
-DCMAKE_CXX_COMPILER=clang-cl.exe
-DCMAKE_CXX_COMPILER_TARGET=arm64ec-pc-windows-msvc
-DCMAKE_LINKER_TYPE=MSVC
```

#147357 attempted to fix an MSVC in sysinfo.cc by adding a `case` block
for a missing enum value.

However, this resulted in [CI
failures](https://github.com/llvm/llvm-project/pull/147357#issuecomment-3079709852):
```
4.170 [148/4/9] Building CXX object third-party/benchmark/src/CMakeFiles/benchmark.dir/sysinfo.cc.obj
FAILED: third-party/benchmark/src/CMakeFiles/benchmark.dir/sysinfo.cc.obj 
C:\Users\tcwg\scoop\shims\ccache.exe C:\Users\tcwg\scoop\apps\llvm-arm64\current\bin\clang-cl.exe  /nologo -TP -DBENCHMARK_STATIC_DEFINE -DEXPERIMENTAL_KEY_INSTRUCTIONS -DHAVE_STD_REGEX -DHAVE_STEADY_CLOCK -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/third-party/benchmark/src -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/src -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/include -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/llvm/include -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- -Werror=unguarded-availability-new   -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported /Gw /W4  -EHs-  -EHa- /O2 /Ob2  -std:c++14 -MD -UNDEBUG /showIncludes /Fothird-party/benchmark/src/CMakeFiles/benchmark.dir/sysinfo.cc.obj /Fdthird-party\benchmark\src\CMakeFiles\benchmark.dir\benchmark.pdb -c -- C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/src/sysinfo.cc
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/src/sysinfo.cc(374,12): error: use of undeclared identifier 'CacheUnknown'
  374 |       case CacheUnknown:
      |            ^
1 error generated.
```

The root cause is that the enum being switched on is defined in the
Windows SDK, so depending on which version of the SDK you are using
`CacheUnknown` may or may not be defined.

The correct fix here is to use a `default` block in the switch statement
instead.

Building LLVM with MSVC is raising the following warning:

```
llvm\third-party\benchmark\src\sysinfo.cc(375): warning C4062: enumerator 'CacheUnknown' in switch of enum '_PROCESSOR_CACHE_TYPE' is not handled
```

This change resolves the warning by moving the `Unknown` type into a
case block for `CacheUnknown`.

Not sure how this code flows back into the original source.

Add the top-level LLVM include directory to the `llvm_gtest` target, as
it requires `llvm/Support/raw_os_ostream.h` header. This fixes a
flang-rt unittest build failure introduced in #143682.

The original commit removed them to avoid the dependency on llvm Support
because of LLVM_FALLTHROUGH, but this triggers `-Wimplicit-fallthrough`
warnings.

LLVM requires a C++17 compiler now, so we should be able to use the
standard [[fallthrough]] attribute.

This is so that we'll be able to use it in compiler-rt as well.
Dependencies on LLVM Support were removed from the header by restoring
code from the original SipHash implementation.

Reviewers: kuhar, dwblaikie, ahmedbougacha

Reviewed By: dwblaikie

Pull Request: https://github.com/llvm/llvm-project/pull/134197