Despite a great review from @labath, I accidentally landed the signal
with the UID and PID properties flipped. I was actually trying to write
tests for this feature when I discovered it.

This fixes that bug, and add a shell test that runs only on Nix systems.

After https://github.com/llvm/llvm-project/pull/141670, TestLinuxCore.py
was timing out on our Windows on Arm bot.

Non-Linux core files were ok, as were Linux core files unless it was
ppc64le, riscv64 or loongarch.

I eventually noticed that it was attempting to create PlatformLinux many
times before trying PlatformAndroid, PlatformMac etc., which it should
never need to do.

The tests passed on a Linux host too, to add to the mystery.

Turns out, all I needed to do was mark those architectures as supported
in the PlatformLinux constructor. If they're not listed there we get
stuck here:
```
    // Wait for a stopped event since we just posted one above...
	printf("waiting for process to stop...\n");
    lldb::EventSP event_sp;
    StateType state =
        WaitForProcessToStop(std::nullopt, &event_sp, true, listener_sp,
                             nullptr, true, SelectMostRelevantFrame);
    printf("process stopped\n");
```
Waiting for a stop event that never comes, because it appears we try to
treat the core as a real process?
```
 DynamicLoaderPOSIXDYLD::virtual DynamicLoaderPOSIXDYLD::DidAttach pid 28147 executable '<null executable>', load_offset 0xffffffffffffffff
<...>
 Process::ShouldBroadcastEvent (000002ABC43FF4A0) Restarting process from state: stopped
 Process::PrivateResume() m_stop_id = 1, public state: unloaded private state: stopped
 Process::PrivateResume() got an error "error: elf-core does not support resuming processes".
 Process::ShouldBroadcastEvent (000002ABC43FF4A0) => new state: stopped, last broadcast state: invalid - NO
```
Some actionable feedback here would be nice, but all I care about for
now is that the tests run again.

I have not added riscv32 as that appears to only be supported for Darwin
at the moment (I expect someone will get burned by this when it is).

I think debug on these architectures worked if they were also the host
arch, if someone tried to remote debug them, I think it would have
failed.

Another iteration of fixes for #141670. Platform linux can be used by
other platforms, so we need to supply the signal values if they're not
defined.

Values are from the
[manpage](https://man7.org/linux/man-pages/man7/signal.7.html)

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.

In most places, the rows are copied anyway (because they are generated
by cumulating modifications) immediately after adding them to the unwind
plans. In others, they can be moved into the unwind plan. This lets us
remove some backflip copies and make `const UnwindPlan` actually mean
something.

I've split this patch into two (and temporarily left both APIs) as this
patch was getting a bit big. This patch covers all the interesting
cases. Part two all about converting "architecture default" unwind plans
from ABI and InstructionEmulation plugins.

This patch converts TagTypeKind into scoped enum. Among other benefits,
this allows us to forward-declare it where necessary.

This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.

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