Add a mock driver to pass CMake's compiler introspection for
CMake_Fortran_COMPILER. It's purpose is to not having to build the full
flang compiler for the runtimes-configure phase in
bootstrapping-runtimes builds, but only when the Fortran compiler is
actually needed (e.g. flang-rt-mod, libomp-mod).
To detect LLVMFlang, CMake executes
```
${CMAKE_Fortran_COMPILER} -v -c -target=... CMakeFortranCompilerId.F
```
and expects a new file to appear in the working directory. This would
usually be an object file (e.g. ELF), but it doesn't matter for CMake as
it parses it for the preprocessor result of CMakeFortranCompilerId.F
which would appear as string literals in the binary file (CMake cannot
execute the file because it might be cross-compiling). Just passing it
through the preprocessor yields the same result. The most relevant
preprocessor definition is __flang__ which leads to
CMAKE_Fortran_COMPILER_ID="LLVMFlang".
This is more robust than #198205:
1. It does not rely on `CMake_Fortran_COMPILER_FORCED` which the CMake
manual documents as [Do not
use](https://cmake.org/cmake/help/latest/module/CMakeForceCompiler.html),
nor the undocumented `CMAKE_Fortran_COMPILER_ID_RUN`.
2. Incremental builds are more robust, there should be no risk of the
make program (ninja/make) mistakenly interpreting the empty/mock
executable as the up-to-date build artifact. Creating the shim/empty
flang executable is done in the outer bootstrapping built (rather than
in the inner runtimes build); having control over both rules that create
bin/flang allows this.
Also fixes the problem that check-flang-rt/check-openmp [do not trigger
(re-)building
flang](https://github.com/llvm/llvm-project/pull/198205#pullrequestreview-4412291879).
I think it should fix intermittend failures of the premerge-CI such as
https://github.com/llvm/llvm-project/actions/runs/27389890881/job/80947804137?pr=203400.
Design considerations:
* This relies on the way how CMake currently introspects the compiler.
However, I expect it to stay "look into the produced files" in the
foreseable future and will also not rely on runtime string concatenation
because debug builds may not ptimize them into a single string constant.
That is, there are reasons CMake can only rely on the preprocessor. The
Fortran standard does not mandate a preprocessor, yet CMake relies on
it.
* There is one situation where incremental builds to not completely
work: deleting bin/flang manually and then building runtimes-configure
will not recreate either bin/flang. No impact if runtimes-configure was
actually run before because in that case CMake has already cached the
CMAKE_Fortran_COMPILER inspection result.
* ninja does not allow two rules to create the same file (one to create
bin/flang only if it is missing and another that replaces it with the
full flang), one of the build artifacts must be undeclared. That could
be the full flang would only be created explicitly with a separate
`flang-eager` target (flang itself have the output
`bin/flang-<version>`, `bin/flang` is the symlink to it), but that would
require more intrusive changes.
3fee6e5ab4