Main executables were bypassing the locate module callback that shared 
libraries use, preventing custom symbol file location logic from working
consistently. 

This PR fix this by
*   Adding target context to ModuleSpec
* Leveraging that context to use target search path and platform's
locate module callback in ModuleList::GetSharedModule

This ensures both main executables and shared libraries get the same 
callback treatment for symbol file resolution.

---------

Co-authored-by: George Hu <hyubo@meta.com>
Co-authored-by: George Hu <georgehuyubo@gmail.com>

The `ProcessElfCore::FindModuleUUID` function can be called by multiple
threads at the same time when `target.parallel-module-load` is true. We
were using the `operator[]` to lookup the UUID which will mutate the map
when the key is not present. This is unsafe in a multi-threaded contex
so we now use a read-only `find` operation and explicitly return an
invalid UUID when the key is not present.

The `m_uuids` map can follow a create-then-query pattern. It is
populated in the `DoLoadCore` function which looks like it is only
called in a single-threaded context so we do not need extra locking as
long as we keep the other accesses read-only.

Other fixes I considered

* Use a lock to protect access - We don't need to modify the map after
creation so we can allow concurrent read-only access.
* Store the map in a const pointer container to prevent accidental
mutation in other places.
     - Only accessed in one place currently so just added a comment.
* Store the UUID in the NT_FILE_Entry after building the mapping
correctly in `UpdateBuildIdForNTFileEntries`. - The map lets us avoid a
linear search in `FindModuleUUID`.

This commit also reverts the temporary workaround from #159395 which
disabled parallel module loading to avoid the test failure.

Fixes #159377

If `pr_name` is longer than 16, it would be a non-null terminated
string. Assigning it to `std::string m_executable_name` would cause an
overflow read. Instead, just copy the name from thread_data.name.

To repro, run the `elf-core/TestLinuxCore.py` with asan
(Question: why is the new variable needed in the first place? can't the
thread_data.name be used?)

This change improves how LLDB's ProcessElfCore plugin identifies the
main executable when loading ELF core files. Previously, the code would
simply use the first entry in the NT_FILE section, which is not
guaranteed to be the main executable, also the first entry might not
have a valid UUID.

1. **Storing executable name**: Extract the executable name from the ELF
NT_PRPSINFO note and store it in `m_executable_name`

2. **Preferential matching**: When selecting the main executable from
NT_FILE entries, prefer entries whose path ends with the stored
executable name

3. **UUID-based lookup**: Call `FindModuleUUID()` helper function to
properly match modules by path and retrieve a valid UUID

Co-authored-by: George Hu <hyubo@meta.com>

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 some core file, we are seeing that it's not always the case that the
ELF header would exist in the first region in NT_FILES section.
Therefore the FindModuleUUID is not able to find the module UUID by just
returning the first entry with path matching.

This fix change the behavior to continue search the NT_FILE entries
until finding a valid UUID with path matching.

Co-authored-by: George Hu <georgehuyubo@gmail.com>

This commit addresses a bug introduced in commit bcf654c, which
prevented LLDB from parsing the GNU build ID for the main executable
from a core file. The fix finds the `p_vaddr` of the first `PT_LOAD`
segment as the `base_addr` and subtract this `base_addr` from the
virtual address being read.

Co-authored-by: George Hu <hyubo@meta.com>

ELF core debugging fix #117070 broke TestLoadUnload.py tests due to
GetModuleSpec call, ProcessGDBRemote fetches modules from remote. Revise
the original PR, renamed FindBuildId to FindModuleUUID.