Part of https://github.com/llvm/llvm-project/pull/149827

This patch adds special handling for `AsmLabel`s created by LLDB. LLDB
uses `AsmLabel`s to encode information about a function declaration to
make it easier to locate function symbols when JITing C++ expressions.
For constructors/destructors LLDB doesn't know at the time of creating
the `AsmLabelAttr` which structor variant the expression evaluator will
need to call (this is decided when compiling the expression). So we make
the Clang mangler inject this information into our custom label when
we're JITting the expression.

This was added purely for the needs of LLDB. However, starting with
https://github.com/llvm/llvm-project/pull/151355 and
https://github.com/llvm/llvm-project/pull/148877 we no longer create
literal AsmLabels in LLDB either. So this is unused and we can get rid
of it.

In the near future LLDB will want to add special support for mangling
`AsmLabel`s (specifically
https://github.com/llvm/llvm-project/pull/149827).

When implementing `@objcDirect` in Swift, Swift needs to mangle a native
`Decl` that is not a clang Node, which in turn don't have access to
`clang::MangleContext`. Reimplementing mangling logic in Swift is
redundant.

This patch moves mangling logic from `clang::MangleContext` to `clang`
using only basic types (`StringRef`, `std::optional`, etc.), such that
Swift can we can just call Clang API: Swift depends on Clang already.

We are separating this from #126639 so we can draft the proposal on the
Swift side. #126639 will be worked to depend on this PR.

Tests: No new tests, old ones should pass with no problem.

---------

Signed-off-by: Peter Rong <PeterRong@meta.com>

When given an invalid Objective-C extension, Clang would crash when
trying to emit the mangled name of the method to the JSON dump output.

Fixes #137320

This feature is currently not supported in the compiler.
To facilitate this we emit a stub version of each kernel
function body with different name mangling scheme, and
replaces the respective kernel call-sites appropriately.
    
Fixes https://github.com/llvm/llvm-project/issues/60313
    
D120566 was an earlier attempt made to upstream a solution
for this issue.

---------

Co-authored-by: anikelal <anikelal@amd.com>

Unfortunately, making `MangleContext::mangleName()` would require a lot
of const escapes due to lazy initialization and id creations:

`Mangle.h`:
*
https://github.com/llvm/llvm-project/blob/dffbc030e75b758e7512518abd499a0f680addbf/clang/include/clang/AST/Mangle.h#L82-L85
*
https://github.com/llvm/llvm-project/blob/dffbc030e75b758e7512518abd499a0f680addbf/clang/include/clang/AST/Mangle.h#L97-L99

`ItaniumMangle.cpp`:
*
https://github.com/llvm/llvm-project/blob/dffbc030e75b758e7512518abd499a0f680addbf/clang/lib/AST/ItaniumMangle.cpp#L158-L161
*
https://github.com/llvm/llvm-project/blob/4508d6aa72b0f31056ae01aff0e8009a252e4683/clang/lib/AST/ItaniumMangle.cpp#L641

`MicrosoftMangle.cpp`:
*
https://github.com/llvm/llvm-project/blob/dffbc030e75b758e7512518abd499a0f680addbf/clang/lib/AST/MicrosoftMangle.cpp#L243-L245
*
https://github.com/llvm/llvm-project/blob/dffbc030e75b758e7512518abd499a0f680addbf/clang/lib/AST/MicrosoftMangle.cpp#L284

Instead of hardcoding the decision on what mangling scheme to use based
on targets, use TargetInfo to make the decision.

Identified with misc-include-cleaner.

* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Strip unneeded calls to raw_string_ostream::str(), to avoid extra indirection.

Virtual function pointer entries in v-tables are signed with address
discrimination in addition to declaration-based discrimination, where an
integer discriminator the string hash (see
`ptrauth_string_discriminator`) of the mangled name of the overridden
method. This notably provides diversity based on the full signature of
the overridden method, including the method name and parameter types.
This patch introduces ItaniumVTableContext logic to find the original
declaration of the overridden method.
On AArch64, these pointers are signed using the `IA` key (the
process-independent code key.)

V-table pointers can be signed with either no discrimination, or a
similar scheme using address and decl-based discrimination. In this
case, the integer discriminator is the string hash of the mangled
v-table identifier of the class that originally introduced the vtable
pointer.
On AArch64, these pointers are signed using the `DA` key (the
process-independent data key.)

Not using discrimination allows attackers to simply copy valid v-table
pointers from one object to another. However, using a uniform
discriminator of 0 does have positive performance and code-size
implications on AArch64, and diversity for the most important v-table
access pattern (virtual dispatch) is already better assured by the
signing schemas used on the virtual functions. It is also known that
some code in practice copies objects containing v-tables with `memcpy`,
and while this is not permitted formally, it is something that may be
invasive to eliminate.

This is controlled by:
```
  -fptrauth-vtable-pointer-type-discrimination
  -fptrauth-vtable-pointer-address-discrimination
```

In addition, this provides fine-grained controls in the
ptrauth_vtable_pointer attribute, which allows overriding the default
ptrauth schema for vtable pointers on a given class hierarchy, e.g.:
```
  [[clang::ptrauth_vtable_pointer(no_authentication, no_address_discrimination, 
                                  no_extra_discrimination)]]
  [[clang::ptrauth_vtable_pointer(default_key, default_address_discrimination,
                                  custom_discrimination, 0xf00d)]]
```

The override is then mangled as a parametrized vendor extension:
```
"__vtptrauth" I
 <key>
 <addressDiscriminated>
 <extraDiscriminator>
E
```

To support this attribute, this patch adds a small extension to the
attribute-emitter tablegen backend.

Note that there are known areas where signing is either missing
altogether or can be strengthened. Some will be addressed in later
changes (e.g., member function pointers, some RTTI).
`dynamic_cast` in particular is handled by emitting an artificial
v-table pointer load (in a way that always authenticates it) before the
runtime call itself, as the runtime doesn't have enough information
today to properly authenticate it. Instead, the runtime is currently
expected to strip the v-table pointer.

---------

Co-authored-by: John McCall <rjmccall@apple.com>
Co-authored-by: Ahmed Bougacha <ahmed@bougacha.org>