Support for `qMemTags` packet in debugserver which allows usage of
LLDB's `memory tag read` on Darwin.

Now that all uses of PThreadMutex have been migrated to their C++
equivalent, this PR removes PThreadMutex itself.

If lldb tries to attach to a process that is marked 'Translated' with
debugserver, it will exec the Rosetta debugserver to handle the debug
session without checking if it is present. If there is a configuration
that is somehow missing this, it will fail poorly.

rdar://135641680

This way debugserver can correctly report qProcessInfo for arm64
processes on arm64e-capable hosts.

Patch implemented with help from Jason Molenda!

Currently when you interrupt a:

(lldb) process attach -w -n some_process

lldb just closes the connection to the stub and kills the
lldb_private::Process it made for the attach. The stub at the other end
notices the connection go down and exits because of that. But when
communication to a device is handled through some kind of proxy server
which isn't as well behaved as one would wish, that signal might not be
reliable, causing debugserver to persist on the machine, waiting to
steal the next instance of that process.

We can work around those failures by sending an explicit interrupt
before closing down the connection. The stub will also have to be
waiting for the interrupt for this to make any difference. I changed
debugserver to do that.

I didn't make the equivalent change in lldb-server. So long as you
aren't faced with a flakey connection, this should not be necessary.

On the Swift forums, people are disabling SIP in order to debug process
that are missing the get-task-allow entitlement. Improve the error to
give developers a hint at the potential issues.

rdar://113704200

Differential revision: https://reviews.llvm.org/D157640

When we attach to a process, we task_for_pid(), ptrace(), and then
we try to halt execution of the process and time out after thirty
seconds if we cannot interrupt it.  At this point, we must assume
we have no control of the inferior process and the attach has failed.
The error message we return currently is "operation timed out"; this
change improves on that error message to make it more clear what is
going on.  Thanks to Jim for pointing this out.

rdar://101152233

When debugserver is attaching to a process, it first task_for_pid()'s
and then ptrace(PT_ATTACHEXC)'s.  When that ptrace() fails to complete,
we are in a semi-attached state that we need to give up from, and
our error reporting isn't ideal -- we can even claim that the process
is already being debugged (by ourselves).

Differential Revision: https://reviews.llvm.org/D155037
rdar://101152233

DNBGetDeploymentInfo was calling GetPlatformString w/o checking that
the load command it was processing actually provided a platform string.
That caused a bunch of worrisome looking error messages in the debugserver
log output.

Differential Revision: https://reviews.llvm.org/D151861

jGetLoadedDynamicLibrariesInfos has a mode where it will list
every binary in the process - the load address and filepath from dyld
SPI, and the mach-o header and load commands from a scan by debugserver
for perf reasons.  With a large enough number of libraries, creating
that StructuredData representation of all of this, and formatting it
into an ascii string to send up to lldb, can grow debugserver's heap
size too large for some environments.

This patch adds a new report_load_commands:false boolean to the
jGetLoadedDynamicLibrariesInfos packet, where debugserver will now
only report the dyld SPI load address and filepath for all of the
binaries.  lldb can then ask for the detailed information on
the process binaries in smaller chunks, and avoid debugserver
having ever growing heap use as the number of binaries inevitably
increases.

This patch also removes a version of jGetLoadedDynamicLibrariesInfos
for pre-iOS 10 and pre-macOS 10.12 systems where we did not use
dyld SPI.  We can't back compile to those OS builds any longer
with modern Xcode.

Finally, it removes a requirement in DynamicLoaderMacOS that the
JSON reply from jGetLoadedDynamicLibrariesInfos include the
mod_date field for each binary.  This has always been reported as
0 in modern dyld, and is another reason for packet growth in
the reply.  debugserver still puts the mod_date field in its replies
for interop with existing lldb's, but we will be able to remove it
the field from debugserver's output after the next release cycle
when this patch has had time to circulate.

I'll add lldb support for requesting the load addresses only
and splitting the request up into chunks in a separate patch.

Differential Revision: https://reviews.llvm.org/D150158
rdar://107848326