d076608d58d1ec55016eb747a995511e3a3f72aa moved some deps around to avoid
cycles and left clang/Frontend/FrontendDiagnostic.h as a shim that
simply includes clang/Basic/DiagnosticFrontend.h. This PR inlines it so
that nothing in tree still includes clang/Frontend/FrontendDiagnostic.h.

Doing this will help prevent future layering issues. See #162865.

Frontend already depends on Basic, so no new deps need to be added
anywhere except for places that do strict dep checking.

This PR implements `CompilerInstanceWithContext` to improve by-name
dependency queries.

Cases exist where we query the dependency of different names, with
otherwise identical working directory and compile command line inputs.
In these cases, we can create one `CompilerInstance`, whose lifetime is
the same as the dependency scanning worker, and reuse the same compiler
instance to complete the queries. This way we reduce the amount of
header search we need to perform per query, since the already completed
header search results are cached in the compiler instance.

Using a microbenchmark on a prototype of this implementation, we are
seeing a scanning performance improvement of about 20%. The
microbenchmark scans a Swift file that imports everything importable.
When measuring against a set of internal project builds, the geo mean of
total build time improvement is around 1.02x to 1.04x depending on
whether the module caches are populated or not.

Part of work for rdar://136303612.

Developers reported non-deterministic output from `-module-file-info`,
thinking this reflected non-determinism in the .pcm files themselves.
However, it turned out it was the printing that was non-deterministic:

```
$ cat /tmp/a.h
#define FOO 1
#define BAR 2

$ build/bin/clang -cc1 -std=c++20 -x c++ -emit-header-unit /tmp/a.h -o /tmp/a.pcm

$ build/bin/clang -cc1 -module-file-info /tmp/a.pcm | grep -A2 Definitions
   Macro Definitions:
     FOO
     BAR

$ build/bin/clang -cc1 -module-file-info /tmp/a.pcm | grep -A2 Definitions
   Macro Definitions:
     BAR
     FOO
```

Making the output deterministic also simplifies the test.

This is a follow-up to 360c5fe54c0758c73bf85453fd2913f371adc7d5

This pr implements support for a root signature as a target, as specified
[here](https://github.com/llvm/wg-hlsl/blob/main/proposals/0029-root-signature-driver-options.md#target-root-signature-version).

This is implemented in the following steps:
1. Add `rootsignature` as a shader model environment type and define
`rootsig` as a `target_profile`. Only valid as versions 1.0 and 1.1
2. Updates `HLSLFrontendAction` to invoke a special handling of
constructing the `ASTContext` if we are considering an `hlsl` file and
with a `rootsignature` target
3. Defines the special handling to minimally instantiate the `Parser`
and `Sema` to insert the `RootSignatureDecl`
4. Updates `CGHLSLRuntime` to emit the constructed root signature decl
as part of `dx.rootsignatures` with a `null` entry function
5. Updates `DXILRootSignature` to handle emitting a root signature
without an entry function
6. Updates `ToolChains/HLSL` to invoke `only-section=RTS0` to strip any
other generated information

Resolves: https://github.com/llvm/llvm-project/issues/150286.

##### Implementation Considerations
Ideally we could invoke this as part of `clang-dxc` without the need of
a source file. However, the initialization of the `Parser` and `Lexer`
becomes quite complicated to handle this.

Technically, we could avoid generating any of the extra information that
is removed in step 6. However, it seems better to re-use the logic in
`llvm-objcopy` without any need for additional custom logic in
`DXILRootSignature`.

Resolves warnings triggered by `Woverloaded-virtual`

This pr implements the functionality of `rootsig-define` as described
[here](https://github.com/llvm/wg-hlsl/blob/main/proposals/0029-root-signature-driver-options.md#option--rootsig-define).

This is accomplished by:
- Defining the `fdx-rootsignature-define`, and `rootsig-define` alias,
driver options. It simply specifies the name of a macro that will expand
to a `LiteralString` to be interpreted as a root signature.
- Introduces a new general frontend action wrapper,
`HLSLFrontendAction`. This class allows us to introduce `HLSL` specific
behaviour on the underlying action (primarily `ASTFrontendAction`).
Which will be further extended, or modularly wrapped, when considering
future DXC options.
- Using `HLSLFrontendAction` we can add a new `PPCallback` that will
eagerly parse the root signature specified with `rootsig-define` and
push it as a `TopLevelDecl` to `Sema`. This occurs when the macro has
been lexed.
- Since the root signature is parsed early, before any function
declarations, we can then simply attach it to the entry function once it
is encountered. Overwriting any applicable root signature attrs.

Resolves https://github.com/llvm/llvm-project/issues/150274

##### Implementation considerations

To implement this feature, note that:
1. We need access to all defined macros. These are created as part of
the first `Lex` in `Parser::Initialize` after `PP->EnterMainSourceFile`
2. `RootSignatureDecl` must be added to `Sema` before
`Consumer->HandleTranslationUnit` is invoked in `ParseAST`

Therefore, we can't handle the root signature in
`HLSLFrontendAction::ExecuteAction` before (from 1.) or after (from 2.)
invoking the underlying `ASTFrontendAction`.

This means we could alternatively:
- Manually handle this case
[here](https://github.com/llvm/llvm-project/blob/ac8f0bb070c9071742b6f6ce03bebc9d87217830/clang/lib/Parse/ParseAST.cpp#L168)
before parsing the first top level decl.
- Hook into when we [return the entry function
decl](https://github.com/llvm/llvm-project/blob/ac8f0bb070c9071742b6f6ce03bebc9d87217830/clang/lib/Parse/Parser.cpp#L1190)
and then parse the root signature and override its `RootSignatureAttr`.

The proposed solution handles this in the most modular way which should
work on any `FrontendAction` that might use the `Parser` without
invoking `ParseAST`, and, is not subject to needing to call the hook in
multiple different places of function declarators.

Preprocessing the preprocessor output again interacts poorly with some
flag combinations when we perform a separate preprocessing stage. In our
case, `-no-integrated-cpp -dD` triggered this issue; but I guess that
other flags could also trigger problems (`-save-temps` instead of
`-no-integrated-cpp`).

Full context (which is quite weird I'll admit):

* To cache OpenCL kernel compilation results, we use the
`-no-integrated-cpp` for the driver to generate a separate preprocessing
command (`clang -E`) before the rest of the compilation.
* Some OpenCL C language features are implemented as macro definitions
(in `opencl-c-base.h`). The semantic analysis queries the preprocessor
to check if these are defined or not, for example, when we checks if a
builtin is available when using `-fdeclare-opencl-builtins`.
* To preserve these `#define` directives, on the preprocessor's output,
we use `-dD`. However, other `#define` directives are also maintained
besides OpenCL ones; which triggers the issue shown in this PR.

A better fix for our particular case could have been to move the
language features implemented as macros into some sort of a flag to be
used together with `-fdeclare-opencl-builtins`.
But I also thought that not preprocessing preprocessor outputs seemed
like something desirable. I hope to work on this on a follow up.

Some `LangOptions` duplicate their `CodeGenOptions` counterparts. My
understanding is that this was done solely because some infrastructure
(like preprocessor initialization, serialization, module compatibility
checks, etc.) were only possible/convenient for `LangOptions`. This PR
implements the missing support for `CodeGenOptions`, which makes it
possible to remove some duplicate `LangOptions` fields and simplify the
logic. Motivated by https://github.com/llvm/llvm-project/pull/146342.

This removes the `{BENIGN,COMPATIBLE}{,_ENUM,_VALUE}_LANGOPT` X macros
controlling `LangOptions`. These are permutations of the base `LANGOPT`,
`ENUM_LANGOPT` and `VALUE_LANGOPT` X macros that also carry the
information of their effect on AST (and therefore module compatibility).
Their functionality is now implemented by passing `Benign`, `Compatible`
or `NotCompatible` argument to the base X macros and using C++17 `if
constexpr` in the clients to achieve the same codegen.

This PR solves this FIXME:
```
// FIXME: Clients should be able to more easily select whether they want
// different levels of compatibility versus how to handle different kinds
// of option.
```

The base X macros are preserved, since they are used in `LangOptions.h`
to generate different kinds of field and function declarations for
flags, values and enums, which can't be achieved with `if constexpr`.

The new syntax also forces developers to think about compatibility when
adding new language option, hopefully reducing the number of new options
that are affecting by default even though they are benign or compatible.

Note that the `BENIGN_` macros used to forward to their `COMPATIBLE_`
counterparts. I don't think this ever kicked in, since there are no
clients of the `.def` file that define `COMPATIBLE_` without also
defining `BENIGN_`. However, this might be something downstream forks
need to take care of by doing `if constexpr (CK::Compatibility ==
CK::Benign || CK::Compatibility == CK::Compatible)` in place of `#define
COMPATIBLE_`.

These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.