Using `SmallVector` would introduce a dependency cycle (see
https://github.com/llvm/llvm-project/pull/155630#discussion_r2495268497),
so this uses a NodeList.

When there's a deep inheritance hierarchy of multiple C++ classes (see
below), then the mangled name of a VFTable can include multiple key
nodes in the target name.
For example, in the following code, MSVC will generate mangled names for
the VFTables that have up to three key classes in the context.
<details><summary>Code</summary>

```cpp
class Base1 {
  virtual void a() {};
};
class Base2 {
  virtual void b() {}
};

class Ind1 : public Base1 {};
class Ind2 : public Base1 {};

class A : public Ind1, public Ind2 {};

class Ind3 : public A {};
class Ind4 : public A {};

class B : public Ind3, public Ind4 {};

class Ind5 : public B {};
class Ind6 : public B {};

class C : public Ind5, public Ind6 {};

int main() { auto i = new C; }
```
</details> 

This will include `??_7C@@6BInd1@@Ind4@@Ind5@@@` (and every other
combination). Microsoft's undname will demangle this to "const
C::\`vftable'{for \`Ind1's \`Ind4's \`Ind5'}". Previously, LLVM would
demangle this to "const C::\`vftable'{for \`Ind1'}".

With this PR, the output of LLVM's undname will be identical to
Microsoft's version. This changes `SpecialTableSymbolNode::TargetName`
to a node array which contains each key from the name. Unlike
namespaces, these keys are not in reverse order - they are in the same
order as in the mangled name.

The qualifier allows programmer to directly control how pointers are
signed when they are stored in a particular variable.

The qualifier takes three arguments: the signing key, a flag specifying
whether address discrimination should be used, and a non-negative
integer that is used for additional discrimination.

```
typedef void (*my_callback)(const void*);
my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback;
```

Co-Authored-By: John McCall rjmccall@apple.com

Static analysis detected that Demangler::demangleStringLiteral had a
potential overflow if not checking StringByteSize properly.

Added check to ensure that for wide string it is always even and that
there were the byte count did not mismatch the actual size of the
literal.

Fixes: https://github.com/llvm/llvm-project/issues/129970

Arm64EC uses a special name mangling mode that adds `$$h` between the
symbol name and its type. In MSVC's name mangling `@` is used to
separate the name and type BUT it is also used for other purposes, such
as the separator between paths in a fully qualified name.

The original algorithm was quite fragile and made assumptions that
didn't hold true for all MSVC mangled symbols, so instead of trying to
improve this algorithm we are now using the demangler to indicate where
the insertion point should be (i.e., to parse the fully-qualified name
and return the current string offset).

Also fixed `isArm64ECMangledFunctionName` to search for `@$$h` since the
`$$h` must always be after a `@`.

Fixes #115231

Properly demangle `_T` and `_P` return type manglings for MSVC 1920+.
Also added a unit test for `@` return type that is used when mangling
non-template auto placeholder return type function.

Tested the output against the undname shipped with MSVC 19.40.

Fixes https://github.com/llvm/llvm-project/issues/70899.

This is a continuation of
https://github.com/llvm/llvm-project/pull/92477 for pointers to member
data and pointers to member functions.

The mangled name must be prefixed with `$M <mangled-type>` for the
deduced type of the nttp parameter.

As cited here, https://github.com/llvm/llvm-project/pull/92477, undname
needs updating to support the new auto NTTP name mangling.

In short the deduced type of the auto NTTP parameter is mangled as `$M
<type> <nttp-param>`. However the deduced type is not printed for the
undecorated name so the `$M <type>` is parsed but simply ignored when
stringifying the generated AST.

To fix expensive check builds that were failing when using MSVC's
std::string_view::iterator::operator*, I added a few expressions like
&*std::string_view::begin.  @nico pointed out that this is literally the
same thing and more clearly expressed as std::string_view::data.

Link: https://github.com/llvm/llvm-project/issues/63740

Reviewed By: #libc_abi, ldionne, philnik, MaskRay

Differential Revision: https://reviews.llvm.org/D154876