This PR mirrors changes of `__compressed_pair_padding` in libc++ into
lldb test suite.

Related PR for libc++:
- #108956
- #109028
- #142125

This relands changes in #144424 for adding a count of DWO files
parsed/loaded and the total number of DWO files.

The previous PR was reverted in #145494 due to the newly added unit
tests failing on Windows and MacOS CIs since these platforms don't
support DWO. This change add an additional
`@add_test_categories(["dwo"])` to the new tests to
[skip](https://github.com/llvm/llvm-project/blob/cd46354dbd10820158edabe14dbd49d9f9010722/lldb/packages/Python/lldbsuite/test/test_categories.py#L56)
these tests on Windows/MacOS.

Original PR: #144424

### Testing
Ran unit tests
```
$ bin/lldb-dotest -p TestStats.py llvm-project/lldb/test/API/commands/statistics/basic/
----------------------------------------------------------------------
Ran 24 tests in 211.391s

OK (skipped=3)
```

Reverts llvm/llvm-project#144424

Caused CI failures.

macOS CI failure was:
```
10:20:36  FAIL: test_dwp_dwo_file_count (TestStats.TestCase)
10:20:36      Test "statistics dump" and the loaded dwo file count.
10:20:36  ----------------------------------------------------------------------
10:20:36  Traceback (most recent call last):
10:20:36    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py", line 639, in test_dwp_dwo_file_count
10:20:36      self.assertEqual(debug_stats["totalDwoFileCount"], 2)
10:20:36  AssertionError: 0 != 2
10:20:36  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
10:20:36  ======================================================================
10:20:36  FAIL: test_no_debug_names_eager_loads_dwo_files (TestStats.TestCase)
10:20:36      Test the eager loading behavior of DWO files when debug_names is absent by
10:20:36  ----------------------------------------------------------------------
10:20:36  Traceback (most recent call last):
10:20:36    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py", line 566, in test_no_debug_names_eager_loads_dwo_files
10:20:36      self.assertEqual(debug_stats["totalDwoFileCount"], 2)
10:20:36  AssertionError: 0 != 2
10:20:36  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
10:20:36  ======================================================================
10:20:36  FAIL: test_split_dwarf_dwo_file_count (TestStats.TestCase)
10:20:36      Test "statistics dump" and the dwo file count.
10:20:36  ----------------------------------------------------------------------
10:20:36  Traceback (most recent call last):
10:20:36    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py", line 588, in test_split_dwarf_dwo_file_count
10:20:36      self.assertEqual(len(debug_stats["modules"]), 1)
10:20:36  AssertionError: 42 != 1
10:20:36  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
```

## Summary
A new `totalLoadedDwoFileCount` and `totalDwoFileCount` counters to
available statisctics when calling "statistics dump".

1. `GetDwoFileCounts ` is created, and returns a pair of ints
representing the number of loaded DWO files and the total number of DWO
files, respectively. An override is implemented for `SymbolFileDWARF`
that loops through each compile unit, and adds to a counter if it's a
DWO unit, and then uses `GetDwoSymbolFile(false)` to check whether the
DWO file was already loaded/parsed.

3. In `Statistics`, use `GetSeparateDebugInfo` to sum up the total
number of loaded/parsed DWO files along with the total number of DWO
files. This is done by checking whether the DWO file was already
successfully `loaded` in the collected DWO data, anding adding to the
`totalLoadedDwoFileCount`, and adding to `totalDwoFileCount` for all CU
units.

## Expected Behavior
- When binaries are compiled with split-dwarf and separate DWO files,
`totalLoadedDwoFileCount` would be the number of loaded DWO files and
`totalDwoFileCount` would be the total count of DWO files.
- When using a DWP file instead of separate DWO files,
`totalLoadedDwoFileCount` would be the number of parsed compile units,
while `totalDwoFileCount` would be the total number of CUs in the DWP
file. This should be similar to the counts we get from loading separate
DWO files rather than only counting whether a single DWP file was
loaded.
- When not using split-dwarf, we expect both `totalDwoFileCount` and
`totalLoadedDwoFileCount` to be 0 since no separate debug info is
loaded.

## Testing
**Manual Testing**
On an internal script that has many DWO files, `statistics dump` was
called before and after a `type lookup` command. The
`totalLoadedDwoFileCount` increased as expected after the `type lookup`.
```
(lldb) statistics dump
{
  ...
  "totalLoadedDwoFileCount": 29,
}
(lldb) type lookup folly::Optional<unsigned int>::Storage
typedef std::conditional<true, folly::Optional<unsigned int>::StorageTriviallyDestructible, folly::Optional<unsigned int>::StorageNonTriviallyDestructible>::type
typedef std::conditional<true, folly::Optional<unsigned int>::StorageTriviallyDestructible, folly::Optional<unsigned int>::StorageNonTriviallyDestructible>::type
...
(lldb) statistics dump
{
  ...
  "totalLoadedDwoFileCount": 2160,
}
```
**Unit test**
Added three unit tests that build with new "third.cpp" and "baz.cpp"
files. For tests with w/ flags `-gsplit-dwarf -gpubnames`, this
generates 2 DWO files. Then, the test incrementally adds breakpoints,
and does a type lookup, and the count should increase for each of these
as new DWO files get loaded to support these.
```
$ bin/lldb-dotest -p TestStats.py ~/llvm-sand/external/llvm-project/lldb/test/API/commands/statistics/basic/
----------------------------------------------------------------------
Ran 20 tests in 211.738s

OK (skipped=3)
```

test_common is force-included into every compilation, which causes
problems when we're compiling assembly code, as we were in #138805.

This avoids that as we can include the header only when it's needed.

As discussed with @DavidSpickett in discord. Running the test runner
caused the following issue:

```
gmake: Entering directory '/home/kper/oss/llvm-project/build/lldb-test-build.noindex/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.test'
/home/kper/oss/llvm-project/build/bin/clang++  -std=c++11 -g -O0  -mriscv -I/home/kper/oss/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/home/kper/oss/llvm-project/build/tools/lldb/include -I/home/kper/oss/llvm-project/lldb/test/API/functionalities/thread/concurrent_events -I/home/kper/oss/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /home/kper/oss/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h -fno-limit-debug-info      --driver-mode=g++ -MT main.o -MD -MP -MF main.d -c -o main.o /home/kper/oss/llvm-project/lldb/test/API/functionalities/thread/concurrent_events/main.cpp
clang++: error: unknown argument: '-mriscv'
gmake: *** [Makefile.rules:619: main.o] Error 1
```

By overriding the flags, we avoid the `-mriscv`.

With this patch, vector registers can be read and written when debugging a live process.

Note: We currently assume that all LoongArch64 processors include the
LSX and LASX extensions.

To add test cases, the following modifications were also made:
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/packages/Python/lldbsuite/test/make/Makefile.rules

Reviewed By: DavidSpickett, SixWeining

Pull Request: https://github.com/llvm/llvm-project/pull/120664

Got caught out by this because simply specifying `DYLIB_CXX_SOURCES`
(without specifying `DYLIB_NAME`) resulted in linker errors because the
dylib was never built (and linked). We should probably make that a
Makefile error (though I haven't audited when exactly not specifying
`DYLIB_NAME` is valid; looked like that can happen when we specify
`FRAMEWORK`).

Relands https://github.com/llvm/llvm-project/pull/108375 which had to be
reverted because it was failing on the Windows buildbot. Trying to
reland this with `msvc::no_unique_address` on Windows.

## Purpose
Running the LLDB API tests against a remote Android target with NDK
version r22 or later fails to compile the test inferiors. NDK r21 from
2021 is the most recent NDK that still works with the LLDB API tests.
This PR updates the Android make rules to support newer Android NDK
versions (r19 and later).

## Overview
* Updates and simplifies `Android.rules` to match the newer Android NDK
unified toolchain layout introduced in NDK r19
* Sets `OBJCOPY` and `ARCHIVER` env vars, required by a few test cases,
to their `llvm-` versions in the unified toolchain
* Drops support for pre-2019 Android NDK versions to keep the rules
simple
* Provides an error message if the tests are run using an incompatible
NDK layout

## Problem Details
Android introduced a unified tools layout in NDK r19 (2019) and removed
the old layout in r22 (2021). Releases r19, r20, and r21 support both
the old and new layout side-by-side. More details are in #106270.

## Validation
Ran a sub-set of the LLDB API tests against remote Android targets for
the four primary architectures i386, x86_64, arm, and aarch64. No
validation was done against riscv targets.

For each case, ran the copy of `lldb-server` from the Android NDK on the
device with the latest LLDB test cases in llvm-project

Ran tests with both r19 (the oldest supported) and r26 (more recent,
unified layout only) NDK versions.

Example test command for aarch64:
```
./build/bin/lldb-dotest --out-of-tree-debugserver --arch aarch64 --platform-name remote-android --platform-url connect://localhost:5432 --platform-working-dir /data/local/tmp --compiler=$ANDROID_NDK_ROOT/toolchains/llvm/prebuilt/linux-x86_64/bin/clang lldb/test/API/android/
```
**NOTE: there are a lot of test failures when running the full suite
(especially against 32-bit ARM target). These failures occur independent
of this change.**

Verified the expected error message appears when attempting to run using
NDK r18
```
Build Command Output:
make: Entering directory '/home/andrew/src/llvm/llvm-project/build/lldb-test-build.noindex/android/platform/TestDefaultCacheLineSize.test_cache_line_size'
/home/andrew/src/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/make/Android.rules:16: *** "No unified toolchain sysroot found in /home/andrew/Android/Sdk/ndk/18.1.5063045/toolchains/llvm/prebuilt/linux-x86_64/bin/../../../../... NDK must be r19 or later.".  Stop.
make: Leaving directory '/home/andrew/src/llvm/llvm-project/build/lldb-test-build.noindex/android/platform/TestDefaultCacheLineSize.test_cache_line_size'
```

## Impact
**This change explicitly removes support for the pre-2019 NDK
structure.** Only NDK r19 (from 2019) and later can be used when running
the LLDB API tests. If the maintainers object, we can easily support
both the old and new NDK toolchain layouts side-by-side at the cost of
readability/maintainability. Since this change only impacts tests, I
don't see much value in supporting NDKs that are over 5 years old.

## Guidance to Reviewers
* I am not an expert on `clang` arguments so if anything looks off let
me know.
* While I personally thing supporting 5+ year old NDKs for testing seems
unnecessary, please chime-in if you are concerned with dropping that
support. I can easily revise to support both old and new layouts
side-by-side.
* If there are any specific tests you'd like me to run I will do my best
to accommodate. It doesn't look like there's much (any?) Android LLDB CI
coverage.