[NativeAOT-LLVM] Implement managed stack traces

[SingleAccretion]

This is a large work item so I am splitting it from #2169.

What we have today: 1) On browser:

• We capture the full stack trace via a JS API when the exception is thrown
• We minimally "demangle" the mangled names that are written into the "names" section. This demangling procedure is not precise. 2) On WASI:
• We have nothing except the raw "unmanaged" stack trace from traps generated when an unhandled exception occurs. This is because WASI lacks APIs that would allow us to access the stack (see also https://github.com/WebAssembly/WASI/issues/159).

The mangled names have so far been an acceptable stop-gap solution, but we can and should do better. The ultimate goal is parity with the implementation on non-WASM targets.

Here's a rough outline of the strategy that would work for the browser targets: 1) Create a WASM object writer that is capable of producing object files with R_WASM_FUNCTION_OFFSET family of relocations. This is needed because LLVM does not support emitting them for the data section. Verify first that the linker is able to process them, however. 2) Emit the upstream stack trace metadata blob using this object writer and function offsets as "RVA"s. 3) Modify runtime code to extract WASM code offsets from the stack trace and use them much like the normal runtime would use RVAs. 4) Think about what (if anything) needs to be done for the ExceptionDispatchInfo functionality to be complete.

WASI is harder... We could push for a stack trace API to be added upstream (for the second time); I think I could create a prototype for Wasmtime, but it would be anyone's guess when and if that goes through.

We can utilize the virtual unwind stack to capture stack traces, by linking all frames and disabling some optimizations, and that would work for Debug builds, but not for Release ones due to the overhead. Of course, stack traces in Debug is better than the current state of "nothing", but it would be much, much better if we could utilize the same approach as for browsers.

[yowl]

WASI is harder... We could push for a stack trace API to be added upstream (for the second time); I think I could create a prototype for Wasmtime, but it would be anyone's guess when and if that goes through.

Maybe relevant: https://github.com/WebAssembly/wasi-sdk/issues/334#issuecomment-1730976179

[SingleAccretion]

https://github.com/dotnet/runtimelab/pull/2677 implements the initial version for browser, with the following NYIs: 1) JSC support (fix JSC, see https://bugs.webkit.org/show_bug.cgi?id=278991). 2) Funclet hiding. 3) Treat native WASM frames as JS frames (or use names from the names section for them). This is a nice-to-have; not required for parity with other targets. 4) Hide compiler-generated helpers (that would on other targets be tail-called).

Cleanup: fix https://github.com/llvm/llvm-project/issues/100733 and define RhpStackTraceIpCanary in native code.