[lld] Cortex-53 843419 Erratum thunks cannot safely use a long-range branch extension thunk

In https://github.com/llvm/llvm-project/pull/170495 we fixed a bug where a Cortex-A53 843419 erratum fix had an out of range relocation as the 843419 hard-coded the branch rather than adding a relocation.

LLD will attempt to place the 843419 within branch range so as to not need a range-extension thunk.

In normal operation
```
Code needing 843419_fix
B 843419_fix
return_from_843419_fix:
...
errata_fix:
...
B return_from_843419_fix
```

If there is a lot of linker generated content, or side-effects due to linker generated content such as sections with huge alignments that move to the next boundary, in between the code needing errata, then the 843419 fix may end up out of branch range and need a range extension thunk.

In https://github.com/llvm/llvm-project/pull/170495 the root cause was the rounding up of the size of the BTI landing pad thunks from 8KiB to 4KiB, as these thunks are added individually rather than grouped, this blew up the size of linker generated content considerably. We fixed that so that the BTI landing pad thunks wouldn't round up the size of these landing pad thunks.

We also made it possible for the Cortex-A53 843419 erratum fix to return via a long-branch thunk just in case the extreme case happened. Unfortunately there is a case when it is not safe to use a long-branch thunk. The branch introduced by the patch is linker, not compiler introduced, therefore we cannot guarantee that x16 is not live. As highlighted in https://github.com/llvm/llvm-project/pull/187955 x16 may indeed be live and the long-range thunk will clobber x16.

With the mitigation for BTI landing pad sizes, we don't expect the 843419 erratum to need a range-extension thunk as the linker's size estimate will be conservative enough to place it close enough.

Possible options:
* Do nothing and hope that x16 isn't live at the patch point, the chances of needing a range extension thunk are very small, and the chances are that x16 won't be live in most functions at the patch point.
* Go back to hard-coding the branch, if a range extension thunk is needed LLD will fail with a relocation out of range error.
* Add a new type of thunk that preserves x16 on the stack. In effect a two part thunk, with the first part pushing x16 on to the stack, and doing the indirect call to the second part. The second part will restore x16 and direct branch to the target.

My thought is that hard-coding the branch is the best compromise between safety, implementation complexity, and how likely this situation is to happen.