This PR lets users provide --debug-only flags with python decorators.
This greatly simplifies the debugging experience in python.

Co-authored-by: Tres <tpopp@users.noreply.github.com>

This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.

This patch adds the logic for collecting stack traces in DebugLoc
instances. We do not symbolize the stack traces in this patch - that
only happens when we decide to actually print them, which will be the
responsibility of debugify. The collection happens in the constructor of
a DebugLoc that has neither a valid location nor an annotation; we also
collect an extra stack trace every time we call setDebugLoc, as
sometimes the more interesting point is not where the DebugLoc was
constructed, but where it was applied to an instruction. This takes the
form of a getCopied() method on DebugLoc, which is the identity function
in normal builds, but adds an extra stack trace in origin-tracking
builds.

This is a generalization of the existing cloneToNewContext operation:
rather than cloning the given module into a new ThreadSafeContext it
clones it into any given ThreadSafeContext. The given ThreadSafeContext
is locked to ensure that the cloning operation is safe.

This removes ThreadSafeContext::Lock, ThreadSafeContext::getLock, and
ThreadSafeContext::getContext, and replaces them with a
ThreadSafeContext::withContextDo method (and const override).

The new method can be used to access an existing
ThreadSafeContext-wrapped LLVMContext in a safe way:

ThreadSafeContext TSCtx = ... ;
TSCtx.withContextDo([](LLVMContext *Ctx) {
  // this closure has exclusive access to Ctx.
});

The new API enforces correct locking, whereas the old APIs relied on
manual locking (which almost no in-tree code preformed, relying instead
on incidental exclusive access to the ThreadSafeContext).

* MCAssembler::evaluateFixup sets MCFixup::PCRel.
* ELFObjectWriter retrieves the bit from the MCFixup argument.

As per #142559, this marks ftrunc as legal for Neon and upgrades the existing
arm.neon.vrintz intrinsics.

This PR adds `llvm::fill` that accepts a range instead of begin/end
iterator.

Follow-up to #141333. Relocation generation called both addReloc and
applyFixup, with the default addReloc invoking shouldForceRelocation,
resulting in three virtual calls. This approach was also inflexible, as
targets needing additional data required extending
`shouldForceRelocation` (see #73721, resolved by #141311).

This change integrates relocation handling into applyFixup, eliminating
two virtual calls. The prior default addReloc is renamed to
maybeAddReloc. Targets overriding addReloc now call their customized
addReloc implementation.

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

Reloc list reference:
```
+ Already handled
A Added in this change
= Not applicable / expected (though technically legal, e. g. you can relocate v128.const...)

+ R_WASM_FUNCTION_INDEX_LEB,      0
+ R_WASM_TABLE_INDEX_SLEB,        1
= R_WASM_TABLE_INDEX_I32,         2
+ R_WASM_MEMORY_ADDR_LEB,         3
+ R_WASM_MEMORY_ADDR_SLEB,        4
= R_WASM_MEMORY_ADDR_I32,         5
+ R_WASM_TYPE_INDEX_LEB,          6
+ R_WASM_GLOBAL_INDEX_LEB,        7
= R_WASM_FUNCTION_OFFSET_I32,     8
= R_WASM_SECTION_OFFSET_I32,      9
+ R_WASM_TAG_INDEX_LEB,          10
A R_WASM_MEMORY_ADDR_REL_SLEB,   11
A R_WASM_TABLE_INDEX_REL_SLEB,   12
= R_WASM_GLOBAL_INDEX_I32,       13
+ R_WASM_MEMORY_ADDR_LEB64,      14
+ R_WASM_MEMORY_ADDR_SLEB64,     15
= R_WASM_MEMORY_ADDR_I64,        16
A R_WASM_MEMORY_ADDR_REL_SLEB64, 17
+ R_WASM_TABLE_INDEX_SLEB64,     18
= R_WASM_TABLE_INDEX_I64,        19
+ R_WASM_TABLE_NUMBER_LEB,       20
A R_WASM_MEMORY_ADDR_TLS_SLEB,   21
= R_WASM_FUNCTION_OFFSET_I64,    22
= R_WASM_MEMORY_ADDR_LOCREL_I32, 23
A R_WASM_TABLE_INDEX_REL_SLEB64, 24
A R_WASM_MEMORY_ADDR_TLS_SLEB64, 25
= R_WASM_FUNCTION_INDEX_I32,     26
```