SIGWINCH is sent when the terminal window size changes.. Most people
debugging do not want the process on this signal.

When using lldb-dap, the user may be using an integrated terminal and
may resize the pane/window mulitple times when debugging. this causes
the signal to be sent multiple times. It gets in the way.

The process ignores this signal by default

The register set information is stored as a singleton in
GetRegisterInfo_i386. However, other functions later access this
information assuming it is stored in GetSharedRegisterInfoVector. To
resolve this inconsistency, we remove the original construction logic
and instead initialize the singleton using llvm::call_once within the
appropriate function (GetSharedRegisterInfoVector_i386).

uintptr_t is usually a good idea when handling pointers, but lldb has to
handle 64-bit addresses that might be from a remote system, on a 32-bit
system.

So I've changed a few instances here to use addr_t which is 64-bit
everywhere.

Before we got:
https://lab.llvm.org/buildbot/#/builders/18/builds/21247

```
../llvm-project/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp:81:28: error: constexpr variable 'g_mte_tag_mask' must be initialized by a constant expression
   81 | static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift;
      |                            ^                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../llvm-project/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp:81:61: note: shift count 56 >= width of type 'uintptr_t' (aka 'unsigned int') (32 bits)
   81 | static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift;
      |                                                             ^
1 error generated.
```

Original code added by #159117.

Recognize an MTE tag fault Mach exception. A tag fault is an error
reported by Arm's Memory Tagging Extension (MTE) when a memory access
attempts to use a pointer with a tag that doesn't match the tag stored
with the memory. LLDB will print the tag and address to make the issue
easier to diagnose.

This was hand tested by debugging an MTE enabled binary on an iPhone 17
running iOS 26.

rdar://113575216

This avoids the following kind of warning with GCC:

    warning: control reaches end of non-void function [-Wreturn-type]

Unlike x86, ARM doesn't support a generic thread pointer for TLS data,
so things like
```
reg read tp
...
memory read tp
```

Don't work, and you need to specify tpidr. This works, especially
because that's the name GDB uses. But for ease of use, and at the
request of @aperez I've made it so we can reference it via `tp`.

I personally don't have an aarch machine, and all the arm examples in
`Shell/Register/Core` are freebsd and don't contain tpidr, so I was
unable to add a shell test for this. I added a test to the AARCH
register tests, but without an Aarch machine I'm hoping these work.

Which is also used by AArch64 and LoongArch.

To test this, I ran the test suite as usual on Arm and found no new 
failures, then ran it again with all test programs compiled with
`-mthumb`. This means the binaries will be entirely Thumb code.

Finally I tested it on AArch64, but this is mostly a build test,
as I did not run the entire test suite compiled to AArch32.

Prior to this change, these tests failed with `-mthumb`:
```
Failed Tests (14):
  lldb-api :: commands/process/reverse-continue/TestReverseContinue.py
  lldb-api :: functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py
  lldb-api :: functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
  lldb-api :: functionalities/reverse-execution/TestReverseContinueBreakpoints.py
  lldb-api :: functionalities/reverse-execution/TestReverseContinueWatchpoints.py
  lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
  lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
  lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
  lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
  lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
  lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
  lldb-api :: functionalities/thread/jump/TestThreadJump.py
  lldb-api :: lang/c/vla/TestVLA.py
  lldb-api :: linux/sepdebugsymlink/TestTargetSymbolsSepDebugSymlink.py
```

After this change, no new failures occurred. So I am confident it is
correct / as bad as it always was.

Looking at those failures, it's a few things:
* Something in the reverse execution wrapper that I can't figure out,
but is
  likely nothing to do with the real breakpoints.
* The inability to tail call when building thumb code, because the call
goes
  via. a veneer that might do a mode switch.
* Assumptions about source locations being in specific places.

None of which are issues I feel like need fixing before doing this port.

I suspect there is redundant code in this, particularly aligning
addresses. I've not made an effort to remove it because A: I'm scared to
break Thumb support because it's not commonly used and B: it may be
there to handle clients other than LLDB, which don't align breakpoint
addresses before requesting them.

When providing allocation and deallocation traces,
the ASan compiler-rt runtime already provides call
addresses (`TracePCType::Calls`).

On Darwin, system sanitizers (libsanitizers)
provides return address.  It also discards a few
non-user frames at the top of the stack, because
these internal libmalloc/libsanitizers stack
frames do not provide any value when diagnosing
memory errors.

Introduce and add handling for
`TracePCType::ReturnsNoZerothFrame` to cover this
case and enable libsanitizers traces line-level
testing.

rdar://157596927

---
Commit 1 is a mechanical refactoring to introduce
and adopt `TracePCType` enum to replace
`pcs_are_call_addresses` bool.  It preserve the
current behavior:
```
pcs_are_call_addresses:
  false  ->  TracePCType::Returns (default)
  true   ->  TracePCType::Calls
``` 

Best reviewed commit by commit.

This reverts commit 600976f4bfb06526c283dcc4efc4801792f08ca5.

The test was crashing trying to access any element of the GPR struct.

(gdb) disas
Dump of assembler code for function _ZN7testing8internal11CmpHelperEQIyyEENS_15AssertionResultEPKcS4_RKT_RKT0_:
   0x00450afc <+0>:	push	{r4, r5, r6, r7, r8, r9, r10, r11, lr}
   0x00450b00 <+4>:	sub	sp, sp, #60	; 0x3c
   0x00450b04 <+8>:	ldr	r5, [sp, #96]	; 0x60
=> 0x00450b08 <+12>:	ldm	r3, {r4, r7}
   0x00450b0c <+16>:	ldm	r5, {r6, r9}
   0x00450b10 <+20>:	eor	r7, r7, r9
   0x00450b14 <+24>:	eor	r6, r4, r6
   0x00450b18 <+28>:	orrs	r7, r6, r7

(gdb) p/x r3
$3 = 0x3e300f6e

"However, load and store multiple instructions (LDM and STM) and load and store double-word (LDRD or STRD) must be aligned to at least a word boundary."

https://developer.arm.com/documentation/den0013/d/Porting/Alignment

>>> 0x3e300f6e % 4
2

Program received signal SIGBUS, Bus error.
0x00450b08 in testing::AssertionResult testing::internal::CmpHelperEQ<unsigned long long, unsigned long long>(char const*, char const*, unsigned long long const&, unsigned long long const&) ()

The struct is packed with 1 byte alignment, but it needs to start at an aligned address for us
to ldm from it. So I've done that with alignas.

Also fixed some compiler warnings in the test itself.