Currently `OutputBuffer::GtIsGt` is used to tell us if we're inside
template arguments and have printed a '(' without a closing ')'. If so,
we don't need to quote '<' when printing it as part of a binary
expression inside a template argument. Otherwise we need to. E.g.,
```
foo<a<(b < c)>> // Quotes around binary expression needed.
```

LLDB's `TrackingOutputBuffer` has heuristics that rely on checking
whether we are inside template arguments, regardless of the current
parentheses depth. We've been using `isGtInsideTemplateArgs` for this,
but that isn't correct. Resulting in us incorrectly tracking the
basename of function like:
```
void func<(foo::Enum)1>()
```
Here `GtIsGt > 0` despite us being inside template arguments (because we
incremented it when seeing '(').

This patch adds a `isInsideTemplateArgs` API which LLDB will use to more
accurately track parts of the demangled name.

To make sure this API doesn't go untested in the actual libcxxabi
test-suite, I changed the existing `GtIsGt` logic to use it. Also
renamed the various variables/APIs involved to make it (in my opinion)
more straightforward to understand what's going on. But happy to rename
it back if people disagree.

Also adjusted LLDB to use the newly introduced API (and added a
unit-test that would previously fail).

## Purpose

This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `Demangle` interface with
a new `DEMANGLE_ABI` annotation, which behaves like the `LLVM_ABI`. This
annotation currently has no meaningful impact on the LLVM build;
however, it is a prerequisite to support an LLVM Windows DLL (shared
library) build.

## Overview

1. Add a new `Demangle/Visibility.h` header file that defines a new
`DEMANGLE_ABI` macro. The macro resolves to the proper DLL export/import
annotation on Windows and a "default" visibility annotation elsewhere.
2. Add a new `LLVM_ENABLE_DEMANGLE_EXPORT_ANNOTATIONS ` `#cmakedefine`
that is used to gate the definition of `DEMANGLE_ABI`.
3. Code-mod annotate the public `Demangle` interface using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool.
4. Manually fix-up `#include` statements for consistency.
5. Format the changes with `clang-format`.
6. Add a "stub" version of `Visibility.h` under `libcxxabi/src/demangle`
that always defines `DEMANGLE_ABI` to nothing.
7. Update the canonical `libcxxabi/src/demangle/ItaniumDemangle.h`
instead of the llvm copy, and run `cp-to-llvm.sh` to ensure the llvm
copy matches. NOTE: we rely on `ccp-to-llvm.sh` not copying
`Visibillity.h` as is already the case for `DemangleConfig.h`.

## Background

This PR follows the pattern established with the `llvm-c` changes made
in #141701.

This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).

## Validation

Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:

- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang

---------

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

The front-end expects _BitInt to be available for substitution; ensure DB<n> is
added to Subs in ItaniumDemangle.h. Also add a test case to libc++abi and
sync the files to llvm/include/llvm.

76ba29bfd8e8aaf5b0267598d18434a0d13945a2 landed changes in
ItaniumDemangle.h on the LLVM side that were not propagated over to the
libcxxabi side. This patch fixes that.

Compilers can generate mangled names such as `_ZN1CpmEi` which we
currently fail to demangle. The OperatorInfo table only marked the `pt`
operator as being "named", which prevented the others from demangling
properly. Removing this logic for the other kinds of member operators
isn't causing any tests to fail.

And remove now redunant friend declaration.

For some reason this was failing to build on one of the MSVC bots after
https://github.com/llvm/llvm-project/pull/131836:
```
FAILED: tools/lldb/source/Plugins/ExpressionParser/Clang/CMakeFiles/lldbPluginExpressionParserClang.dir/ClangExpressionParser.cpp.obj

ccache C:\PROGRA~1\MICROS~1\2022\COMMUN~1\VC\Tools\MSVC\1441~1.341\bin\Hostx64\x64\cl.exe  /nologo /TP -DCLANG_BUILD_STATIC -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IC:\buildbot\as-builder-10\lldb-x-aarch64\build\tools\lldb\source\Plugins\ExpressionParser\Clang -IC:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\source\Plugins\ExpressionParser\Clang -IC:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\include -IC:\buildbot\as-builder-10\lldb-x-aarch64\build\tools\lldb\include -IC:\buildbot\as-builder-10\lldb-x-aarch64\build\include -IC:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\llvm\include -IC:\Python312\include -IC:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\llvm\..\clang\include -IC:\buildbot\as-builder-10\lldb-x-aarch64\build\tools\lldb\..\clang\include -IC:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\source -IC:\buildbot\as-builder-10\lldb-x-aarch64\build\tools\lldb\source -D__OPTIMIZE__ /Zc:inline /Zc:preprocessor /Zc:__cplusplus /Oi /bigobj /permissive- /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd5105 -wd4324 -wd4251 -wd4275 -w14062 -we4238 /Gw /O2 /Ob2  -MD   -wd4018 -wd4068 -wd4150 -wd4201 -wd4251 -wd4521 -wd4530 -wd4589  /EHs-c- /GR- -UNDEBUG -std:c++17 /showIncludes /Fotools\lldb\source\Plugins\ExpressionParser\Clang\CMakeFiles\lldbPluginExpressionParserClang.dir\ClangExpressionParser.cpp.obj /Fdtools\lldb\source\Plugins\ExpressionParser\Clang\CMakeFiles\lldbPluginExpressionParserClang.dir\lldbPluginExpressionParserClang.pdb /FS -c C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\source\Plugins\ExpressionParser\Clang\ClangExpressionParser.cpp

C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\llvm\include\llvm/Demangle/ItaniumDemangle.h(667): error C2248: 'llvm::itanium_demangle::ObjCProtoName::Protocol': cannot access private member declared in class 'llvm::itanium_demangle::ObjCProtoName'

C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\llvm\include\llvm/Demangle/ItaniumDemangle.h(615): note: see declaration of 'llvm::itanium_demangle::ObjCProtoName::Protocol'

C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\llvm\include\llvm/Demangle/ItaniumDemangle.h(613): note: see declaration of 'llvm::itanium_demangle::ObjCProtoName'
```

It's not quite clear to me why this wasn't compiling but either way this
is cleaner.

This patch includes the necessary changes for the LLDB feature proposed
in
https://discourse.llvm.org/t/rfc-lldb-highlighting-function-names-in-lldb-backtraces/85309.
The TL;DR is that we want to track where certain parts of a demangled
name begin/end so we can highlight them in backtraces.

We introduce a new `printLeft`/`printRight` API on `OutputBuffer` that a
client (in our case LLDB) can implement to track state while printing
the demangle tree. This requires redirecting all calls to to
`printLeft`/`printRight` to the `OutputBuffer`. One quirk with the new
API is that `Utility.h` would now depend on `ItaniumDemangle.h` and
vice-versa. To keep these files header-only I made the definitions
`inline` and implement the new APIs in `ItaniumDemangle.h` (so the
definition of `Node` is available to them).

Also introduces `notifyInsertion`/`notifyDeletion` APIs that a client can override to respond to cases where the `OutputBuffer` changes arbitrary parts of the name.

PowerPC uses a slightly different type of floats for their 128 bit long
doubles, as "double-double", with __LDBL_MANT_DIG__ == 106 rather than
__LDBL_MANT_DIG__ == 113 for IEEE 128 bit floats.

This fixes compiling libcxxabi for PowerPC after
3b70715c13876c51542ebfe2e3f4ee908f6785cb.

This avoids needing to hardcode the mapping between architectures and
their sizes of long doubles.

This fixes a case in test_demangle.pass.cpp, that previously failed like
this (XFAILed):

    .---command stdout------------
    | Testing 29859 symbols.
| _ZN5test01hIfEEvRAcvjplstT_Le4001a000000000000000E_c should be invalid
but is not
| Got: 0, void test0::h<float>(char (&) [(unsigned int)(sizeof (float) +
0x0.07ff98f7ep-1022L)])
    `-----------------------------
    .---command stderr------------
| Assertion failed: !passed && "demangle did not fail", file
libcxxabi/test/test_demangle.pass.cpp, line 30338
    `-----------------------------

This testcase is defined within

// Is long double fp80? (Only x87 extended double has 64-bit mantissa)
    #define LDBL_FP80 (__LDBL_MANT_DIG__ == 64)
    ...
    #if !LDBL_FP80
    ...
    #endif

The case failed on x86 architectures with an unusual size for long
doubles, as the test expected the demangler to not be able to demangle
an 80 bit long double (based on the `__LDBL_MANT_DIG__ == 64` condition
in the test). However as the libcxxabi implementation was hardcoded to
demangle 80 bit long doubles on x86_64 regardless of the actual size,
this test failed (by unexpectedly being able to demangle it).

By configuring libcxxabi's demangling of long doubles to match what the
compiler specifies, we no longer hit the expected failures in the
test_demangle.pass.cpp test on Android on x86.

This makes libcxxabi require a GCC-compatible compiler that defines
nonstandard defines like `__LDBL_MANT_DIG__`, but I presume that's
already essentially required anyway.

Requirements on character-like types are updated unconditionally,
because `basic_string` does requires the default-constructibility. It
might be possible to make `basic_string_view` support classes with
non-public trivial default constructor, but this doesn't seem sensible.

libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated
features.