This test fails to build on macOS without the correct header include.

I did manage to turn a crash into a non-zero return code,
but on the very first build it managed to time out.

I thought I had the appetite to tweak timeouts but
on second thought, I don't want yet another test to look
out for.

The test is not wrong, but on heavily loaded machines
it's always going to be inherently unstable.

Fixes #101162

This test did this:
* SBDebugger::Initialize
* Spawn a bunch of threads that do:
  * SBDebugger::Create
  * some work
  * SBDebugger::Destroy
* Wait on those threads to finish then call SBDebugger::Terminate and
exit, or -
* Reach a time limit before all the threads finish, call
SBDebugger::Terminate and exit.

The problem was that in the timeout case, calling SBDebugger::Terminate
destroys data being used by threads that are still running. I expect
this test was expecting said threads to be so broken they were probably
stuck, but when the machine is just heavily loaded, one of them might
read that data before the whole program exits.

This means what should have been a timeout becomes a crash. Sometimes.
Which explains why we saw both timeouts and various signals on the
AArch64 Linux bot. It depends on the timings.

So I'm changing it not to call SBDebugger::Terminate in the timeout
case. We will have to tweak the timeout value based on what happens on
the buildbot, but we will know it's machine load not an lldb bug.

Also use _exit instead of exit, to skip more cleanup that might cause a
crash.

This used to timeout (https://github.com/llvm/llvm-project/issues/101162)
now it's aborting (https://github.com/llvm/llvm-project/pull/105765#issuecomment-2327645665)

This test has been flaky lately
(https://github.com/llvm/llvm-project/issues/101162) and I disabled it
everywhere initially.

I found that it always uses "x86_64" for the program architecture so the
test was "passing" elsewhere but I don't think it was meant to. So I
have added a define to pass on the host's architecture when compiling.
This makes it work on AArch64 as well.

While I'm here I've fixed the uint64_t formatting warnings by using the
defined formats that'll work everywhere.

In addition, I found that the function names include "()" on Linux, so
now we check for "foo" or "foo()".

The test cpp file has never been, or was only partially formatted so
I've not formatted the changes, just kept to the local style.

I've removed the Linux skip to see if any of this helps the timeouts,
and to verify the build command changes. If the timeouts come back I'll
disable it again.

This has been flakey lately on Linux on the buildbots and in CI
on PRs.

For example:
https://lab.llvm.org/buildbot/#/builders/59/builds/1324
https://github.com/llvm/llvm-project/pull/98237

I will try to track down the cause tomorrow.

This test occasionally fails on two of the busiest CI bots (asan and
matrix), and we can't reproduce it locally. This leads to the
hypothesis that the test is timing out (in the sense of the number of
"join attempts" performed by this test's driver).

This commit doubles the number of iterations performed and also does
an NFC refactor of the main test loop so that it can be more easily
understood.

We have a handful of tests that build a driver which links against LLDB.
When running those binaries, we overwrite the dynamic loader library
path to point to the build directory's libs dir, presumably to make sure
we load LLDB from there.

This above becomes an issue when you have libc++ enabled and the driver
is linked against the system's libc++, but the dynamic loader flag
forces it to pick up libc++ from the libs dir.

We could try to make the logic for building the driver smarter and have
it pick up the just-built libc++ like we do for our test binaries, but I
don't think we need to overwrite the library path in the first place.
The build logic to build these drivers already takes care to set the
correct RPATH in the linker.

This patch removes the logic and simplifies the tests.

Fix and rename the broken and confusingly named decorator
skipIfHostIncompatibleWithRemote. The decorator is meant to skip test
which uses the inferior test build system (i.e. to build test inferiors)
to build host binaries (e.g. lldb drivers).

The decorator was broken on macOS, where the host and target platform
report macosx, but the decorator overwrote it with Darwin, resulting in
tests incorrectly being skipped.

The decorator was also missing on a handful of tests that use the
buildDriver helper, which this commit fixes as well.

On Darwin, the Makefile already (ad-hoc) signs everything it builds.
There's also no need to use lldb_codesign for this.