- Documented rationale of current solution
- Polished documentation

Fix rust-lang#71798.

When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.

Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.

This commit adds a compiler option which allows a user to force the
addition of unwind tables. Unwind tables cannot be disabled on targets
that require them for correctness, or when using `-C panic=unwind`.

…na-kruppe

Add Option to Force Unwind Tables

When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.

Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In production code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.

---

This came up in discussion on rust-lang#69890, and turned out to be a fairly simple addition.

r? @hanna-kruppe

…wesleywiser

Added MIR constant propagation of Scalars into function call arguments

Now for the function call arguments!

Caveats:
1. It's only being enabled at `mir-opt-2` or higher, because currently codegen gives performance regressions with this optimization.
2. Only propagates Scalars. Tuples and references (references are `Indirect`, right??) are not being propagated into as of this PR.
3. Maybe more tests would be nice?
4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me, and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments.

r? @wesleywiser

doc: misc rustdoc things

Do not try to find binop method on RHS `TyErr`

Fix rust-lang#71798.