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.

Use a flag to determine whether this macro should be set when
intializing the preprocessor.

This macro was added to the driver in
9d117e7b2a399a9b2bcf53fb9b9c0946e82dc75c because it can be conditionally
disabled, but before that, the flag to gate behavior was removed under
the assumption it wasn't conditional in
b5b622a03c5136fa10d245dbe1f8f278ebd98d1b. This patch is to connect the
macro with the preexisting flag

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.

Add a new langopt NativeInt16Type to control support for 16 bit
integers.
Enable by default for all languages but HLSL. 
HLSL defines uint16_t and int16_t as a typedef of short. If
-enable-16bit-types is not used, the typedefs don't exist so int16_t and
uint16_t can't be used. However, short was still allowed. This change
will produce an error 'unknown type name short' if -enable-16bit-types
isn't used.
Update failing tests. 
Add new test.
Closes #81779

From Sam Liu:
>CUDA supports thread block clusters
https://docs.nvidia.com/cuda/cuda-c-programming-guide/#thread-block-clusters
>
>In their atomic intrinsics, cluster scope is supported
https://docs.nvidia.com/cuda/cuda-c-programming-guide/#nv-atomic-fetch-add-and-nv-atomic-add
>
>For compatibility, clang and hip needs to support cluster scope.

Motivated by this discussion:
https://github.com/llvm/llvm-project/pull/163208#discussion_r2426842999

We will soon want to emit language version codes into debug-info.
Instead of replicating the `LangOptions -> version code` mapping we
thought we'd try to share some of the logic with the Clang frontend.

This patch teaches `LangStandard` about language versions (currently just C++ and C).

Wire up the `-fsanitize=alloc-token` command-line option, hooking up
the `AllocToken` pass -- it provides allocation tokens to compatible
runtime allocators, enabling different heap organization strategies,
e.g. hardening schemes based on heap partitioning.

The instrumentation rewrites standard allocation calls into variants
that accept an additional `size_t token_id` argument. For example,
calls to `malloc(size)` become `__alloc_token_malloc(size, token_id)`,
and a C++ `new MyType` expression will call
`__alloc_token__Znwm(size, token_id)`.

Currently untyped allocation calls do not yet have `!alloc_token`
metadata, and therefore receive the fallback token only. This will be
fixed in subsequent changes through best-effort type-inference.

One benefit of the instrumentation approach is that it can be applied
transparently to large codebases, and scales in deployment as other
sanitizers.

Similarly to other sanitizers, instrumentation can selectively be
controlled using `__attribute__((no_sanitize("alloc-token")))`. Support
for sanitizer ignorelists to disable instrumentation for specific
functions or source files is implemented.

See clang/docs/AllocToken.rst for more usage instructions.

Link:
https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434

---

This change is part of the following series:
  1. https://github.com/llvm/llvm-project/pull/160131
  2. https://github.com/llvm/llvm-project/pull/156838
  3. https://github.com/llvm/llvm-project/pull/162098
  4. https://github.com/llvm/llvm-project/pull/162099
  5. https://github.com/llvm/llvm-project/pull/156839
  6. https://github.com/llvm/llvm-project/pull/156840
  7. https://github.com/llvm/llvm-project/pull/156841
  8. https://github.com/llvm/llvm-project/pull/156842

See https://github.com/llvm/llvm-project/issues/71364 for details.

The language of side seems fairly stable.
Setting the feature test macro will ease implementation in standard
libraries.

GCC defines these macros for both userspace and kernel address
sanitizers:

$ gcc -E -dM -fsanitize=address -x c /dev/null &| string match -er
SANITIZE
    #define __SANITIZE_ADDRESS__ 1
$ gcc -E -dM -fsanitize=kernel-address -x c /dev/null &| string match
-er SANITIZE
    #define __SANITIZE_ADDRESS__ 1
$ gcc -E -dM -fsanitize=hwaddress -x c /dev/null &| string match -er
SANITIZE
    #define __SANITIZE_HWADDRESS__ 1
$ gcc -E -dM -fsanitize=kernel-hwaddress -x c /dev/null &| string match
-er SANITIZE
    #define __SANITIZE_HWADDRESS__ 1

PR #153888 added these same defines for clang but only for the userspace
address sanitizers:

$ clang -E -dM -fsanitize=address -x c /dev/null &| string match -er
SANITIZE
    #define __SANITIZE_ADDRESS__ 1
$ clang -E -dM -fsanitize=kernel-address -x c /dev/null &| string match
-er SANITIZE
$ clang -E -dM -fsanitize=hwaddress -x c /dev/null &| string match -er
SANITIZE
    #define __SANITIZE_HWADDRESS__ 1
$ clang -E -dM -fsanitize=kernel-hwaddress -x c /dev/null &| string
match -er SANITIZE

Match GCC's behavior so that the Linux kernel can eventually drop its
own internal defines.