In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeGenModule entity for every new
module request (via StartModule). However, some of the state such as the
mangle context needs to be preserved to keep the original semantics in
the ever-growing TU.

Fixes: llvm/llvm-project#95581.

cc: @jeaye

With -fsanitize-cfi-icall-experimental-normalize-integers, Clang
appends ".normalized" to KCFI types in CodeGenModule::CreateKCFITypeId,
which changes type hashes also for functions that don't have integer
types in their signatures. However, llvm::setKCFIType does not take
integer normalization into account, which means LLVM generated
functions with KCFI types, e.g. sanitizer constructors, will fail KCFI
checks when integer normalization is enabled in Clang.

Add a cfi-normalize-integers module flag to indicate integer
normalization is used, and append ".normalized" to KCFI types also in
llvm::setKCFIType to fix the type mismatch.

For llvm_linux platform, define the following meaning for bits 9, 10,
11:

- bit 9: set if indirect gotos signing is enabled;
- bit 10: set if type info vtable pointer discrimination is enabled;
- bit 11: set if function pointer type discrimination is enabled.

As part of the LLVM effort to eliminate debug-info intrinsics, we're
moving to a world where only iterators should be used to insert
instructions. This isn't a problem in clang when instructions get
generated before any debug-info is inserted, however we're planning on
deprecating and removing the instruction-pointer insertion routines.

Scatter some calls to getIterator in a few places, remove a
deref-then-addrof on another iterator, and add an overload for the
createLoadInstBefore utility. Some callers passes a null insertion
point, which we need to handle explicitly now.

Treat 8th bit of version value for llvm_linux platform as signed GOT
flag.

- clang: define `PointerAuthELFGOT` LangOption and set 8th bit of
  `aarch64-elf-pauthabi-version` LLVM module flag correspondingly;

- llvm-readobj: print `PointerAuthELFGOT` or `!PointerAuthELFGOT` in
  version description of llvm_linux platform depending on whether the flag
  is set.

This reverts commit d3f8105c65046173e20c4c59394b4a7f1bbe7627.

Halide no longer relies on this target:
https://github.com/llvm/llvm-project/pull/98497#issuecomment-2253358685

If both `-fptrauth-init-fini` and `-fptrauth-calls` are passed, sign
function pointers in `llvm.global_ctors` and `llvm.global_dtors` with
constant discriminator 0xD9D4
(`ptrauth_string_discriminator("init_fini")`). Additionally, if
`-fptrauth-init-fini-address-discrimination` is passed, address
discrimination is used for signing (otherwise, just constant
discriminator is used).

For address discrimination, we use it's special form since uses of
`llvm.global_{c|d}tors` are disallowed (see
`Verifier::visitGlobalVariable`) and we can't emit `getelementptr`
expressions referencing these special arrays. A signed ctor/dtor pointer
with special address discrimination applied looks like the following:

```
ptr ptrauth (ptr @foo, i32 0, i64 55764, ptr inttoptr (i64 1 to ptr))
```

See the attached test for the motivation example. If we're too greedy to
not emit the definition for inline builtins, we may meet a middle end
crash. And it should be good to emit inline builtins always.

This patch replaces getAs with castAs and dyn_cast with cast to ensure
type safety and prevents potential null pointer dereferences. These
changes enforce compile-time checks for correct type casting in
ASTContext and CodeGenModule.

This reverts commit ca8a4111f796fe8533e0af95557875b15becff06.
This patch broke clang test on Windows x64 msvc