Fixes #50041

Types will no longer default to `()`, instead always defaulting to `!`.
This disables the associated warning and removes the flag from TyTuple

Consolidate `trans_apply_param_substs` and
`trans_apply_param_substs_env`. Also remove `trans_impl_self_ty`

In particular:

- `fully_normalize_monormophic_ty` => `normalize_erasing_regions`
- `normalize_associated_type_in_env` => `normalize_erasing_regions`
- `fully_normalize_associated_types_in` => `normalize_erasing_regions`
- `erase_late_bound_regions_and_normalize` => `normalize_erasing_late_bound_regions`

This commit is targeted at addressing #48251 by specifically fixing a case where
a longjmp over Rust frames on MSVC runs cleanups, accidentally running the
"abort the program" cleanup as well. Added in #46833 `extern` ABI functions in
Rust will abort the process if Rust panics, and currently this is modeled as a
normal cleanup like all other destructors.

Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the
same mechanism used to implement panics in Rust. This means that `longjmp` over
Rust frames will run Rust cleanups (even though we don't necessarily want it
to). Notably this means that if you `longjmp` over a Rust stack frame then that
probably means you'll abort the program because one of the cleanups will abort
the process.

After some discussion on IRC it turns out that `longjmp` doesn't run cleanups
for *caught* exceptions, it only runs cleanups for cleanup pads. Using this
information this commit tweaks the codegen for an `extern` function to
a catch-all clause for exceptions instead of a cleanup block. This catch-all is
equivalent to the C++ code:

    try {
        foo();
    } catch (...) {
        bar();
    }

and in fact our codegen here is designed to match exactly what clang emits for
that C++ code!

With this tweak a longjmp over Rust code will no longer abort the process. A
longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC.
Other non-MSVC platforms will not rust destructors with a longjmp, so we'll
probably still recommend "don't have destructors on the stack", but in any case
this is a more surgical fix than #48567 and should help us stick to standard
personality functions a bit longer.

We needed to manually added the `DW_OP_deref` ourselves in earlier LLVM,
but starting with [D31439] in LLVM 5, it appears that LLVM will always
handle this itself.  When we were still adding this manually, the
resulting `.debug_loc` had too many derefs, and this failed test
`debuginfo/by-value-self-argument-in-trait-impl.rs`.

[D31439]: https://reviews.llvm.org/D31439

Fixes #47611.
cc @alexcrichton
r? @michaelwoerister

LLVM <= 4.0 used a non-standard interpretation of `DW_OP_plus`.  In the
DWARF standard, this adds two items on the expressions stack.  LLVM's
behavior was more like DWARF's `DW_OP_plus_uconst` -- adding a constant
that follows the op.  The patch series starting with [D33892] switched
to the standard DWARF interpretation, so we need to follow.

[D33892]: https://reviews.llvm.org/D33892

Closes #47278

Initially MIR differentiated between arguments and locals, which
introduced a need to add extra copies assigning the argument to a
local, even for simple bindings. This differentiation no longer exists,
but we're still creating those copies, bloating the MIR and LLVM IR we
emit.

Additionally, the current approach means that we create debug info for
both the incoming argument (marking it as an argument), and then
immediately shadow it a local that goes by the same name. This can be
confusing when using e.g. "info args" in gdb, or when e.g. a debugger
with a GUI displays the function arguments separately from the local
variables, especially when the binding is mutable, because the argument
doesn't change, while the local variable does.

The extra alloca was only necessary because it made LLVM implicitly
handle the necessary deref to get to the actual value. The same happens
for indirect arguments that have the byval attribute. But the Rust ABI
does not use the byval attribute and so we need to manually add the
deref operation to the debuginfo.

Like #43008 (f6689991), but _much more aggressive_.