Normalize before computing ConstArgHasType goal in new solver

[compiler-errors]

This is a fix for #139905. See the description I left in the test.

I chose to fix this by normalizing the type before matching on its .kind() in compute_const_arg_has_type_goal (since it feels somewhat consistent with how we normalize types before assembling their candidates, for example); however, there are several other solutions that come to mind for fixing this ICE:

1. (this solution)
2. Giving ConstKind::Error a proper type, like ConstKind::Value, so that consts don't go from failing to passing ConstArgHasType goals after normalization (i.e. UNEVALUATED would normalize into a ConstKind::Error(_, bool) type rather than losing its type altogether).
3. Just suppressing the errors and accepting the fact that goals can go from fail->pass after normalization.

Thoughts? Happy to discuss this fix further.

r? @BoxyUwU

[rustbot]

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

[lcnr]

not sure if you want boxy to review this, but it feels very much correct to require normalizing before matching on the const kind here :> it's what we do for all other matches on kind as well.

so r=me here

[BoxyUwU]

seems reasonable to me to normalize here. makes a nice property hold. definitely dont want to add a Ty to ConstKind::Error

[BoxyUwU]

@bors r=lcnr,BoxyUwU

[bors]

📌 Commit 87c8aa1 has been approved by lcnr,BoxyUwU

It is now in the queue for this repository.

[BoxyUwU]

I guess more thought: I like to think of it kind of like if const items had ConstArgHasType item bounds, which drawing a parallel to how alias bounds work for types, shouldnt apply if its not a rigid alias so this does just generally feel more consistent to me