This reverts commit d9e659c538516036e40330b6a98160cbda4ff100.

I could not reproduce the Mac OS ASAN failure locally but I narrowed it
down to the test `test_many_fields_same_enum`. This test shares an enum
between x0, which is 64 bit, and cpsr, which is 32 bit.

My theory is that when it does `register read x0`, an enum type is
created where the undlerying enumerators are 64 bit, matching the
register size.

Then it does `register read cpsr` which used the cached enum type, but
this register is 32 bit. This caused lldb to try to read an 8 byte value
out of a 4 byte allocation:
READ of size 8 at 0x60200014b874 thread T0
<...>
=>0x60200014b800: fa fa fd fa fa fa fd fa fa fa fd fa fa fa[04]fa

To fix this I've added the register's size in bytes to the constructed
enum type's name. This means that x0 uses:
__lldb_register_fields_enum_some_enum_8
And cpsr uses:
__lldb_register_fields_enum_some_enum_4

If any other registers use this enum and are read, they will use the
cached type as long as their size matches, otherwise we make a new type.

Reverts llvm/llvm-project#95768 due to a test failure on macOS with
ASAN:

https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-sanitized/425/console

This teaches lldb to parse the enum XML elements sent by lldb-server,
and make use of the information in `register read` and `register info`.

The format is described in

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html.

The target XML parser will drop any invalid enum or evalue. If we find
multiple evalue for the same value, we will use the last one we find.

The order of evalues from the XML is preserved as there may be good
reason they are not in numerical order.

Currently the logic is generate field information for all registers in
LinuxArm64RegisterFlags and then as we walk the existing register info,
only those that are in that existing info will get the new fields
patched in.

This works fine but on a review for FreeBSD support it was pointed out
that this is not obvious from the source code.

So instead I've allowed the construction of empty lists of fields, and
field detection methods can return an empty field list if they think
that the register will never exist.

Then the pre-existing code will see the empty field list, and never look
for that register in the register info.

I think removing the assert is ok because the GDB classes filter out
empty field lists at runtime, and anyone updating the built in field
information would presumably notice if none of the fields they intended
to add were displayed.

mte_ctrl and svcr are the only registers that need this so far.

There is no extra testing here as the behaviour is the same, it doesn't
add field information to regiters that don't exist. The mechanism is
just clearer now.

This was requested on a review for enum code that added new log
functions.

This represents the enum type that can be assigned to a field using the
`<enum>` element in the target XML.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html

Each enumerator has:
* A non-empty name
* A value that is within the range of the field it's applied to

The XML includes a "size" but we don't need that for anything and it's a
pain to verify so I've left it out of our internal structures. When
emitting XML we'll set size to the size of the register using the enum.

An Enumerator class is added to RegisterFlags and hooked up to the
existing ToXML so lldb-server can use it to emit enums as well.

As enums are elements on the same level as flags, when emitting XML
we'll do so via the registers. Before emitting a flags element we look
at all the fields and see what enums they reference. Then print all of
those if we haven't already done so.

Functions are added to dump enum information for `register info` to use
to show the enum information.

As suggested in a review of some new code for this file, Stream
is more general. The code does not need to know that it's backed
by a string.

The contents of which are mostly SPSR_EL1 as shown in the Arm manual,
with a few adjustments for things Linux says userspace shouldn't concern
itself with.

```
(lldb) register read cpsr
    cpsr = 0x80001000
         = (N = 1, Z = 0, C = 0, V = 0, SS = 0, IL = 0, ...
```

Some fields are always present, some depend on extensions. I've checked
for those extensions using HWCAP and HWCAP2.

To provide this for core files and live processes I've added a new class
LinuxArm64RegisterFlags. This is a container for all the registers we'll
want to have fields and handles detecting fields and updating register
info.

This is used by the native process as follows:
* There is a global LinuxArm64RegisterFlags object.
* The first thread takes a mutex on it, and updates the fields.
* Subsequent threads see that detection is already done, and skip it.
* All threads then update their own copy of the register information
with pointers to the field information contained in the global object.

This means that even though every thread will have the same fields, we
only detect them once and have one copy of the information.

Core files instead have a LinuxArm64RegisterFlags as a member, because
each core file could have different saved capabilities. The logic from
there is the same but we get HWACP values from the corefile note.

This handler class is Linux specific right now, but it can easily be
made more generic if needed. For example by using LLVM's FeatureBitset
instead of HWCAPs.

Updating register info is done with string comparison, which isn't
ideal. For CPSR, we do know the register number ahead of time but we do
not for other registers in dynamic register sets. So in the interest of
consistency, I'm going to use string comparison for all registers
including cpsr.

I've added tests with a core file and live process. Only checking for
fields that are always present to account for CPU variance.

This adds ToXML methods to encode RegisterFlags and its fields into XML
according to GDB's target XML format:

https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html#Target-Description-Format

lldb-server does not use libXML to build XML, so this follows the
existing code that uses strings. Indentation is used so the result is
still human readable.

```
<flags id=\"Foo\" size=\"4\">
  <field name=\"abc\" start=\"0\" end=\"0\"/>
</flags>
```

This is used by lldb-server when building target XML, though no one sets
any fields yet. That'll come in a later commit.

I missed these review comments on https://reviews.llvm.org/D152917
before landing it.