Rollup merge of #149501 - lcnr:no-hard-error-on-norm-failure, r=lqd,oli-obk

CTFE: avoid emitting a hard error on generic normalization failures

Fixes rust-lang/rust#149081.

The fix is quite unsatisfying and should not be necessary, cc rust-lang/rust#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs.

cc ````@rust-lang/types```` I think we should try to fix issue rust-lang/rust#149283 in the near future and then remove this hack again.

I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this:
- we only fetch the MIR in the `eval_to_allocation_raw` query
- figuring out which MIR to use is hard
	- dealing with trivial consts is annoying
	- need to resolve instances for associated consts
	- implementing this by hand is hard
- inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness
	- `try_normalize_after_erasing_regions` generally does two things
		- deal with ambiguity after inlining
		- deal with error tainting issues (please don't, we should stop doing that)
- CTFE could be changed to always silently ignore normalization failures if we're in a generic body
	- hides actual bugs <- went with this option

r? types