After some debugging, I found out ProcessELFCore never updates the
platform. I've updated ProcessElfCore to set the arch and platform
before we parse the Notes.

Reverts llvm/llvm-project#140150

Broke the Darwin tests, but they pass on Linux. Reverting to make the
build healthy while I investigate

Recently, I was on an issue that generated a large number of Coredumps,
and every time in both LLDB and GDB the signal was just `SIGSEGV`.

This was frustrating because we would expect a `SIGSEGV` to have an
address, or ideally even bounds. After some digging I found the
`si_code` consistently was -6. With some help from
[@cdown](https://github.com/cdown), we found neither LLDB or GDB
supports the si_codes sent from [user
space](https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/siginfo.h#L185).

Excerpted from the sigaction man page.
```
       For a regular signal, the following list shows the values which
       can be placed in si_code for any signal, along with the reason
       that the signal was generated.
```

For which I added all of the si_codes to every Linux signal. Now for the
Coredump that triggered this whole investigation we get the accurate and
now very informative summary.

<img width="524" alt="image"
src="https://github.com/user-attachments/assets/5149f781-ef21-4491-a077-8fac862fbc20"
/>


Additionally from @labath's suggestion to move this to platform and
leverage the existing `getSiginfo()` call on thread, we can now inspect
the siginfo struct itself via `thread siginfo`. Giving us another
towards GDB parity on elf cores.

.. by changing the signal stop reason format :facepalm:

The reason this did not work is because the code in
`StopInfo::GetCrashingDereference` was looking for the string "address="
to extract the address of the crash. Macos stop reason strings have the
form
```
  EXC_BAD_ACCESS (code=1, address=0xdead)
```
while on linux they look like:
```
  signal SIGSEGV: address not mapped to object (fault address: 0xdead)
```

Extracting the address from a string sounds like a bad idea, but I
suppose there's some value in using a consistent format across
platforms, so this patch changes the signal format to use the equals
sign as well. All of the diagnose tests pass except one, which appears
to fail due to something similar #115453 (disassembler reports
unrelocated call targets).

I've left the tests disabled on windows, as the stop reason reporting
code works very differently there, and I suspect it won't work out of
the box. If I'm wrong -- the XFAIL will let us know.

Signals 1-32 are matching the default UNIX platform.

There are platform specific ones above 32.

The majority of UnixSignals strings are static in the sense that they do
not change. The overwhelming majority of these strings are string
literals. Using ConstString to manage their lifetime does not make
sense. The only exception to this is one of the subclasses of
UnixSignals, for which I have created a StringSet local to that file
which will guarantee the lifetimes of these StringRefs.

As for the other benefits of ConstString, string uniqueness is not a
concern (as many of them are already string literals) and comparing
signal names and aliases should not be a hot path.

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

There's no reason for GetSignalInfo to return the signal name. All users
of this method only use the return value to determine if the method
succeeded in filling in the output parameters, so let's explicitly make
it a bool instead of a pointer.

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

This is in preparation to remove the uses of ConstString from
UnixSignals.

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

The short names of each signal name and alias only exist as ConstStrings
in this one scenario. For example, GetShortName("SIGHUP") will just give
you "HUP". There's not a good reason the string "HUP" needs to be in the
ConstString StringPool, and that's true for just about every signal
name.

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

On llvm.org and all downstream forks that I'm aware of, SignalCodes are
always created from C string literals. They are never compared to
anything so they take up space in the ConstString StringPool for no
tangible benefit.

I've changed the type here to `const llvm::StringLiteral` instead of
using a `StringRef` or a `const char *` to express intent -- These
strings come from constant data whose lifetime is directly tied to that
of the running process (and are thus safe to store).

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