Unfortunately, in this configuration, the bots are forced to use the
system libcxx, which is too old for what this test is verifying.
In the future, we should re-enable building libcxx with asan on MacOS.

Both of these fail on our Clang-19 macOS bots.

Fails with:
```
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang++  -std=c++11 -g -O0 -isysroot "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk" -arch arm64  -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/tools/lldb/include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h  -fno-limit-debug-info    -nostdlib++ -nostdinc++ -cxx-isystem /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/include/c++/v1/  --driver-mode=g++ -MT main.o -MD -MP -MF main.d -c -o main.o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:3:24: error: __bf16 is not supported on this target
08:19:28  template <> struct Foo<__bf16> {};
08:19:28                         ^
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:5:40: error: __bf16 is not supported on this target
08:19:28  template <> struct Foo<_Float16> : Foo<__bf16> {};
08:19:28                                         ^
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:8:7: error: __bf16 is not supported on this target
08:19:28    Foo<__bf16> f0;
08:19:28        ^
08:19:28  3 errors generated.
08:19:28  make: *** [main.o] Error 1
```

On our Clang-15.0 CI.

 Skip tests that require `-gstructor-decl-linkage-names` on Clang versions that don't support it.

 Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it the flag didn't exist but it was the default behaviour of the compiler anyway.

Drive-by:
- We used to run `self.expect("Bar()")` which would always fail. So the `error=True` would be true even if we didn't pass the `-gno-structor-linkage-names`. So it wasn't testing the behaviour properly. This patch changes these to `self.expect("expr Bar()")`.

Skip tests that require `-gstructor-decl-linkage-names` on Clang
versions that don't support it.

Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it
the flag didn't exist but it was the default behaviour of the compiler
anyway.

Requires a compiler with the changes in https://github.com/llvm/llvm-project/pull/122265

Fixes #157674

On ARM, the presence of a specific bf16 type in the AST is gated by: 
```
bool ARMTargetInfo::hasBFloat16Type() const {
  // The __bf16 type is generally available so long as we have any fp registers.
  return HasBFloat16 || (FPU && !SoftFloat);
}
```

And the target we use when evaluating symbols (derived from the program
file, I think, haven't found it yet) does not enable any of this.

This means that we fall back to __fp16.

So for parts of the testing we just need to expect __fp16 instead, and
others we need to skip because now a class looks like it inherits from
itself.

There's a proper fix here somewhere but I don't know what it is yet.

During debugging applization with __bf16 and _Float16 float types it was
discovered that lldb creates the same CompilerType for them. This can
cause an infinite recursion error, if one tries to create two struct
specializations with these types and then inherit one specialization
from another.