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.

`UnqualPtrTy` didn't always match `llvm::PointerType::getUnqual`:
sometimes it returned a pointer that is not in address space 0 (notably
for SPIRV).

Since `UnqualPtrTy` was used as the "generic" or "default" pointer type,
this patch renames it to `DefaultPtrTy` to avoid confusion with LLVM's
`PointerType::getUnqual`.

fixes #30023

The issue is that for compare exchange builtin, if the type's size is
not power of 2, it creates a temporary of size power of 2, then emit the
compare exchange operation. And later, the results of the compare
exchange operation has two components: 1. a boolean whether or not the
exchange happens. 2. the old value
we are supposed to write the old value into user's "expected" value.
However, in case the type is not power of 2, what we actually wrote to
is the temporary that was created.

The fix is to pass the "expected" address all the way down so it can
wrote to the correct address

Previously when using min_fetch/max_fetch atomics with floating point
types, LLVM would emit a crash. This patch updates the
EmitPostAtomicMinMax function in CGAtomic.cpp to take floating point
types. Included is a clang CodeGen test atomic-ops-float-check-minmax.c
and Sema test atomic-ops-fp-minmax.c.

Update the `operator%` overload that accepts `CharUnits` to return
`CharUnits` to match the other `operator%`. This is more logical than
returning an `int64` and cleans up users that want to continue to do
math with the result.

Many users of this were explicitly comparing against 0. I considered
updating these to compare against `CharUnits::Zero` or even introducing
an `explicit operator bool()`, but they all feel clearer if we update
them to use the existing `isMultipleOf()` function instead.

Clang CodeGen for `__atomic_test_and_set` would emit a `store`
instruction that stores an `i1` value:

```cpp
bool f(void *ptr) {
  return __atomic_test_and_set(ptr, __ATOMIC_RELAXED);
}
```

```llvm
%1 = atomicrmw xchg ptr %0, i8 1 monotonic, align 1
%tobool = icmp ne i8 %1, 0
store i1 %tobool, ptr %atomic-temp, align 1
```

which could lead to suboptimal binary code, for example on x86_64:

```asm
f:
    mov     al, 1
    xchg    byte ptr [rdi], al
    test    al, al
    setne   al
    setne   byte ptr [rsp - 1]
    ret
```

The last `setne` instruction is obviously redundant. This patch fixes
this issue by first zero-extending `%tobool` to an `i8` before the
store. This effectively eliminates the last `setne` instruction in the
binary code sequence. The `test` and `setne` on `al` is kept still,
though.

-----

I'm quite conservative about the codegen in this patch. Vanilla gcc
actually emits simpler code for `__atomic_test_and_set`:

```cpp
bool f(void *ptr) {
  return __atomic_test_and_set(ptr, __ATOMIC_RELAXED);
}
```

```asm
f:
    mov     eax, 1
    xchg    al, BYTE PTR [rdi]
    ret
```

It seems like gcc assumes `ptr` would always point to a valid `bool`
value as required by the ABI. I'm not sure if we should also make this
assumption.

Related to #121943 .

This patch is part of a stack that teaches Clang to generate Key
Instructions metadata for C and C++.

The feature is only functional in LLVM if LLVM is built with CMake flag
LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be
removed.

RFC:
https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668

It isn't used and is redundant with the result pointer type argument.
A more reasonable API would only have LangAS parameters, or IR parameters,
not both. Not all values have a meaningful value for this. I'm also
not sure why we have this at all, it's not overridden by any targets and
further simplification is possible.

Fixes #131476.

For `x86_64` it folds
```
movzbl	t1(%rip), %eax
andb	$1, %al
```
into
```
movzbl	t1(%rip), %eax
```
when run: `clang -S atomic-ops-load.c -o atomic-ops-load.s -O1
--target=x86_64`.

But for riscv replaces:
```
lb	a0, %lo(t1)(a0)
andi	a0, a0, 1
```
with
```
lb	a0, %lo(t1)(a0)
zext.b	a0, a0
``` 
when run: `clang -S atomic-ops-load.c -o atomic-ops-load.s -O1
--target=riscv64`.

This matches the spelling of the keyword in LLVM IR.