`PostAnalysisNormalize` can introduce new `{type_error}`

#![feature(type_alias_impl_trait)]
type Tait = impl Copy;

fn set(x: &isize) -> isize {
    *x
}

fn d(x: Tait) {
    set(x);
}

fn other_define() -> Tait {
    ()
}

fn main() {}

This results in an ICE with rustc src/main.rs -Zvalidate-mir -Zinline-mir=yes

error: concrete type differs from previous defining opaque type use
  --> src/main.rs:13:5
   |
13 |     ()
   |     ^^ expected `&'static isize`, got `()`
   |
note: previous use here
  --> src/main.rs:9:5
   |
9  |     set(x);
   |     ^^^^^^

error: internal compiler error: compiler/rustc_middle/src/mir/tcx.rs:118:21: deref projection of non-dereferenceable ty PlaceTy { ty: {type error}, variant_index: None }


thread 'rustc' panicked at compiler/rustc_middle/src/mir/tcx.rs:118:21:
Box<dyn Any>
stack backtrace:
  15:     0x7f1f7416d320 - rustc_middle[6ec8af473b9179e3]::util::bug::bug_fmt
  16:     0x7f1f7871f15c - <rustc_middle[6ec8af473b9179e3]::mir::tcx::PlaceTy>::projection_ty.cold
  17:     0x7f1f77ccac3c - rustc_mir_transform[ddf46edc4b25c392]::validate::validate_types
  18:     0x7f1f77cc03da - <rustc_mir_transform[ddf46edc4b25c392]::validate::Validator as rustc_mir_transform[ddf46edc4b25c392]::pass_manager::MirPass>::run_pass
  19:     0x7f1f75584745 - rustc_mir_transform[ddf46edc4b25c392]::pass_manager::validate_body
  20:     0x7f1f77204b6c - rustc_mir_transform[ddf46edc4b25c392]::pass_manager::run_passes_inner
  21:     0x7f1f7733d234 - rustc_mir_transform[ddf46edc4b25c392]::optimized_mir

The body of d does not contain any type errors while building, so we actually build a body:
https://gist.github.com/lcnr/70f559aa69c4a733ca28f47b4a247113

We then normalize Tait to {type error}: https://gist.github.com/lcnr/92bde9605c555818cc90ea4e0321a258

Resulting in a deref projection of that type error after inlining: https://gist.github.com/lcnr/138f486799689a556d840f3a172b6068

We've got multiple ways forward here:

• more gracefully handle type errors in mir validation/optimizations
• replace the body with a dummy when normalizing to a type error

I believe this can be triggered with RPIT as well, it'd just be a bit more cumbersome

Reproduce the ICE with rustc src/main.rs -Zvalidate-mir -Zinline-mir=yes, then inspect compiler/rustc_middle/src/mir/tcx.rs and the MIR validation path in rustc_mir_transform. Compare the provided MIR before and after normalization and determine how the {type_error} deref is handled; done means the reproducer reports the type error without an internal compiler error.