Fix handling of unboxed closure type param substitutions

- When selecting an implicit trait impl for an unboxed closure, plumb
  through and use the substitutions from impl selection instead of
  using those from the current param environment in trans, which may
  be incorrect.
- When generating a function declaration for an unboxed closure, plumb
  through the substitutions from the param environment of the closure
  as above.  Also normalize the type to avoid generating duplicate
  declarations due to regions being inconsistently replaced with
  ReStatic elsewhere.
- Do not place the closure type in the self param space when
  translating the unboxed closure callee, etc.  It is not actually
  used, and doing so conflicts with the self substitution from
  default trait methods.

Closes #18661
Closes #18685
Add regression test for #18661
Add regression test for #18685
auto merge of #18688 : bkoropoff/rust/unboxed-closure-subst-fixes, r=nikomatsakis

This resolves some issues that remained after adding support for monomorphizing unboxed closures in trans.

There were a few places where a set of substitutions for an unboxed closure type were dropped on the floor and later recalculated from scratch based on the def ID, but this failed spectacularly when the closure originated from a different param environment.  The substitutions are now plumbed through end-to-end.  Closes #18661

There was also a conflict in the meaning of the self param space within the body of the unboxed closure.  Trans attempted to insert the unboxed closure type as the self type, but this could conflict with the self type from the param environment when an unboxed closure was used within a default method on a trait.  Since the body of an unboxed closure cannot refer to its own self type or value, there's no need for it to actually use the self space.  The downstream consumers of the substitutions in trans do not seem to need it either since they look up the type of the closure some other way, so I just stopped setting it.  Closes #18685.

r? @pcwalton @nikomatsakis