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

Since #157170 this test has been flakey on several LLDB buildbots. I
suspect it's to do with mutli-threading, there are more details in
#159377.

Disable parallel loading for now so we are not spamming people making
unrelated changes.

This is something the StopInfo class manages, so it should be allowed to
compute this rather than having SBThread do so. This code just moves the
computation to methods in StopInfo. It is mostly NFC. The one change
that I actually had to adjust the tests for was a couple of tests that
were asking for the UnixSignal stop info data by asking for the data at
index 1. GetStopInfoDataCount returns 1 and we don't do 1 based indexing
so the test code was clearly wrong. But I don't think it makes sense to
perpetuate handing out the value regardless of what index you pass us.

This patch loads values of the VFP registers from the NT_ARM_VFP note.

Note that a CORE/NT_FPREGSET note is typically present in core dump
files and is used to store the FPA registers. The FPA unit is rare and
obsolete; however, Linux creates the note even if the unit is absent.

Add `stop_description` as a Python convenience property to `SBThread`.

This patch fixes updating persistent variables when memory cannot be
allocated in an inferior process:
```
> lldb -c test.core
(lldb) expr int $i = 5
(lldb) expr $i = 55
(int) $0 = 55
(lldb) expr $i
(int) $i = 5
```

With this patch, the last command prints:
```
(int) $i = 55
```

The issue was introduced in #145599.

If a server does not support allocating memory in an inferior process or
when debugging a core file, evaluating an expression in the context of a
value object results in an error:

```
error: <lldb wrapper prefix>:43:1: use of undeclared identifier '$__lldb_class'
   43 | $__lldb_class::$__lldb_expr(void *$__lldb_arg)
      | ^
```

Such expressions require a live address to be stored in the value
object. However, `EntityResultVariable::Dematerialize()` only sets
`ret->m_live_sp` if JIT is available, even if the address points to the
process memory and no custom allocations were made. Similarly,
`EntityPersistentVariable::Dematerialize()` tries to deallocate memory
based on the same check, resulting in an error if the memory was not
previously allocated in `EntityPersistentVariable::Materialize()`.

As an unintended bonus, the patch also fixes a FIXME case in
`TestCxxChar8_t.py`.

Motivation example:

```
> lldb -c altmain2.core
...
(lldb) var F
(const char *) F = 0x0804a000 ""
```

The variable `F` points to a read-only memory page not dumped to the
core file, so `Process::ReadMemory()` cannot read the data. The patch
switches to `Target::ReadMemory()`, which can read data both from the
process memory and the application binary.

Fixes: https://github.com/llvm/llvm-project/issues/123903

Reviewed By: DavidSpickett, SixWeining

Pull Request: https://github.com/llvm/llvm-project/pull/124059

Extending the conditionals in `AugmentRegisterInfo` to support
alternative names for lldb.

Fixes #124023

There is an exception with register `X8` which is not covered here but
more details can be found in the issue
https://github.com/llvm/llvm-project/issues/127900.