@dmpots and I were investigating a crash when he was developing LLDB
earlier. When I loaded the core I was surprised to see LLDB didn't have
information for the SI_CODE. Upon inspection we had an si_code of `128`,
which is the decimal of SI_KERNEL at `0x80`.

These were overlooked in my last addition of the negative si_codes, and
this patch adds SI_USER and SI_KERNEL to the list, covering us for all
the codes available to all signals.

[Linux reference
link](https://github.com/torvalds/linux/blob/74b4cc9b8780bfe8a3992c9ac0033bf22ac01f19/include/uapi/asm-generic/siginfo.h#L175)


![image](https://github.com/user-attachments/assets/52fa58e6-13d4-48a1-8d82-184c07a47db8)

I kept the code naming the same as what is defined in the Linux source
code. SI_KERNEL to my understanding usually indicates something went
awry in the Kernel itself, but I think adding that additional detail
would not be helpful to most users. @DavidSpickett I'd appreciate your
insight into that.

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.

Now, because we do not support mips debugging, if we compile LLVM on
mips target, would report error `static assertion failed:Value mismatch
for signal number SIGBUS`, so add this condition to avoid error.

This will be sent by Arm's Guarded Control Stack extension when an
invalid return is executed.

The signal does have an address we could show, but it's the PC at which
the fault occured. The debugger has plenty of ways to show you that
already, so I've left it out.

```
(lldb) c
Process 460 resuming
Process 460 stopped
* thread #1, name = 'test', stop reason = signal SIGSEGV: control protection fault
    frame #0: 0x0000000000400784 test`main at main.c:57:1
   54  	  afunc();
   55  	  printf("return from main\n");
   56  	  return 0;
-> 57  	}
(lldb) dis
<...>
->  0x400784 <+100>: ret
```

The new test case generates the signal by corrupting the link register
then attempting to return. This will work whether we manually enable GCS
or the C library does it for us.

(in the former case you could just return from main and it would fault)

This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3.
As discussed in https://reviews.llvm.org/D146668 we'll find another way
forward.

The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is
so that we can create the appropriate UnixSignals object based on an
ArchSpec. Instead of using the ArchSpec, we can instead take advantage
of the Platform associated with the current Target.

This is accomplished by adding a new method to Platform,
CreateUnixSignals, which will create the correct UnixSignals object for
us. We then can use `Platform::GetUnixSignals` and rely on that to give
us the correct signals as needed.

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

By adding signal codes to UnixSignals and adding a new function
where you can get a string with optional address and bounds.

Added signal codes to the Linux, FreeBSD and NetBSD signal sets.
I've checked the numbers against the relevant sources.

Each signal code has a code number, description and printing options.
By default you just get the descripton, you can opt into adding either
a fault address or bounds information.

Bounds signals we'll use the description, unless we have the bounds
values in which case we say whether it is an upper or lower bound
issue.

GetCrashReasonString remains in CrashReason because we need it to
be compiled only for platforms with siginfo_t. Ideally it would
move into NativeProcessProtocol, but that is also used
by NativeRegisterContextWindows, where there would be no siginfo_t.

Reviewed By: JDevlieghere

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

Restore the signal tables to its original glory and mark it as not to be
clang-formatted.