builder/format_args_decompiler: post-rustup(s) cleanups.

[eddyb]

Most of the issues addressed here were introduced in #545:
_{(reviewing this module was left to me but I hadn't gotten around to looking closer at it since then)}

• core::fmt::Arguments::new_v1* is gone but dead code handling it was kept around
• similarly, comments clearly describe ABI having changed but both versions were kept
• all core::panicking::panic_* functions were intercepted, despite only 4 being needed
  • 3 of the 4 are lang items, so only the 4th wanted the name-based check (panic_nounwind_fmt)
  • intercepting wrappers meant their messages were hardcoded in format_args_decompiler, which we both don't need to, nor want to (e.g. the full list of wrappers could easily change)
  • the only "benefit" of this can be seen in the test diffs (#[track_caller]-like behavior), and this PR undoes that, but if we really wanted to, we could more closely mimic #[track_caller] through changes to inlining debuginfo and the actual panic-as-debugPrintf transformation
  • this is also the only buggy area I found: the (also inefficient) string checks against tcx.def_path_str(_) broke down inside core itself (there's a reason declare demangles the mangled name, that one is by necessity absolute), which was being papered over using spurious if ... { return Ok(...); } bypasses to silence warnings (without making such panicking callsites work properly)

Lastly, while not strictly necessary, I went ahead and tried minimizing the diff from 2964d67, for crates/rustc_codegen_spirv/src/builder/format_args_decompiler.rs, as much as I could, to ensure I understand everything that changed ("pieces" -> "template" parsing), and what didn't (fmt::rt::Argument::new_* calls).
_{(this also enabled fixing conflicts in one of my "future Rust-GPU branches" commits, that I couldn't figure out when I first ran into them)}

---

Should probably be reviewed piece-wise, but the last commit moves a lot of stuff around anyway.

[Firestar99]

I'm willing to just approve this without really reviewing it deeply, since I've never looked into our fmt_args_decompiler and I feel like I could spent my time more wisely elsewhere right now.