I've wanted a utility to create a corefile for test purposes given a bit
of memory and regsters, for a while. I've written a few API tests over
the years that needed exactly this capability -- we have several one-off
Mach-O corefile creator utility in the API testsuite to do this. But
it's a lot of boilerplate when you only want to specify some register
contents and memory contents, to create an API test.

This adds yaml2mach-core, a tool that should build on any system, takes
a yaml description of register values for one or more threads,
optionally memory values for one or more memory regions, and can take a
list of UUIDs that will be added as LC_NOTE "load binary" metadata to
the corefile so binaries can be loaded into virtual address space in a
test scenario.

The format of the yaml file looks like

```
cpu: armv7m

# optionally specify the number of bits used for addressing
# (this line is from a different, 64-bit, yaml file)
addressable-bits: 
    num-bits: 39

# optionally specify one or more binary UUID and slide/virtual address to be added as an LC_NOTE
# (this line is from a different, 64-bit, yaml file)
binaries:
  - name: debug-binary.development
    uuid: 67942352-5857-3D3D-90CB-A3F80BA67B04
    virtual-address: 0xfffffff01840c000

threads:
  - regsets: 
     - flavor: gpr 
        registers: [{name: sp, value: 0x2000fe70}, {name: r7, value: 0x2000fe80}, 
                    {name: pc, value: 0x0020392c}, {name: lr, value: 0x0020392d}]

memory-regions:
  # stack memory
  - addr: 0x2000fe70 
    UInt32: [ 0x0000002a, 0x20010e58, 0x00203923, 
              0x00000001, 0x2000fe88, 0x00203911, 
              0x2000ffdc, 0xfffffff9 ]
  # instructions of a function
  - addr: 0x203910 
     UInt8: [ 0xf8, 0xb5, 0x04, 0xaf, 0x06, 0x4c, 0x07, 0x49, 
              0x74, 0xf0, 0x2e, 0xf8, 0x01, 0xac, 0x74, 0xf0 ]
```

and that's all that is needed to specify a corefile where four register
values are specified (the others will be set to 0), and two memory
regions will be emitted.

The memory can be specified as an array of UInt8, UInt32, or UInt64, I
anticipate that some of these corefiles may have stack values
constructed manually and it may be simpler for a human to write them in
a particular grouping of values.

I needed this utility for an upcoming patch for ARM Cortex-M processors,
to create a test for the change. I took the opportunity to remove two of
the "trivial mach-o corefile" creator utilities I've written in the
past, which also restricted the tests to only run on Darwin systems
because I was using the system headers for Mach-O constant values.

rdar://110663219

You cannot use a NamedTempFile with an external process because it may
not be flushed to disk. The safest and most portable approach is to
close the file, call the other process and then unlink the file
manually.

Presumably this works fine on Linux, but it fails on Darwin when
targeting remote-linux.

See https://bugs.python.org/issue29573

Fix cross-compilation of test inferiors on Darwin, targeting remote
Linux. This requires specifying the target triple and using LLD for
linking.

Fixes #150806

We emit a warning when running the test suite remotely that says the
libcxx arguments will be ignored, but because they're set outside the
conditional block, we're not actually do this. Fix the logic by moving
the configuration in the conditional else-block.

This PR adds type summaries for
`std::{string,wstring,u8string,u16string,u32string}` from the MSVC STL.

See https://github.com/llvm/llvm-project/issues/24834 for the MSVC STL
issue.

The following changes were made:

- `dotest.py` now detects if the MSVC STL is available. It does so by
looking at the target triple, which is an additional argument passed
from Lit. It specifically checks for `windows-msvc` to not match on
`windows-gnu` (i.e. MinGW/Cygwin).
- (The main part): Added support for summarizing `std::(w)string` from
MSVC's STL. Because the type names from the libstdc++ (pre C++ 11)
string types are the same as on MSVC's STL, `CXXCompositeSummaryFormat`
is used with two entries, one for MSVC's STL and one for libstdc++.
With MSVC's STL, `std::u{8,16,32}string` is also handled. These aren't
handled for libstdc++, so I put them in `LoadMsvcStlFormatters`.

In lldb-dap, we have existing tests that are known to be unstable when
lldb and lldb-dap are built in the Debug configuration.

This decorator lets us skip those tests in CI jobs that are to slow with
those configurations.

This was split out from #140777 to make the patches smaller.

This patch adds --platform-available-ports option to the dotest.py
script to avoid hardcoded gdb ports in lldb testsuite.

Currently, this option could be helpful in GdbRemoteTestCases (e.g.
TestLldbGdbServer, TestNonStop, TestGdbRemoteThreadsInStopReply,
TestGdbRemotePlatformFile, TestGdbRemote_vCont)

Many LLDB's dotest.py based tests require the `make` tool. If it's not found in Path, they fail with an obscure error and show up as `UNRESOLVED`. On Windows, llvm-lit takes care of MSYS based testing tools like cat, printf, etc., but `make` is not part of that. Let's catch the situation early and check for it at configuration time.

This error isn't fatal: It should fail the build, but not immediately stop the configuration process. There might be other issues further down the line that can be caught in the same buildbot run.

In #102185, toolchain detection for API tests has been rewritten in
Python. Tools paths for tests there are determined from compiler path.

Here tools are taken from `--llvm-tools-dir` dotest.py argument, which
by default refers to the LLVM build directory, unless they are
explicitly redefined in environment variables. It helps to minimize
external dependencies and to maximize the reproducibility of the build.

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>