Keep analyzing items after an undefined type

[LesterEvSe]

Description

An undefined type in a function signature, type alias or enum payload no longer stops the analysis. It is replaced with !, which matches every type, so only the undefined name is reported and its uses are not.

For this code:

type Alias = Missing;
enum E { A(Unknown), B }
fn f(a: (Foo, Bar), b: u32) -> u32 { b }
fn g() -> u32 { y }

fn main() {
    let t: bool = true;
    let r: u32 = f(1, t);
}

On master there is only one error:

Type alias `Missing` is not defined

With this PR:

Type alias `Missing` is not defined
Type alias `Unknown` is not defined
Type alias `Foo` is not defined
Type alias `Bar` is not defined
Variable `y` is not defined
Expected expression of type `u32`, found type `bool`

Note: Like rustc, errors whose types contain ! are not reported until the undefined type is fixed.
Example: let x: Option<Alias> = 5; reports only the undefined Missing.

Limitations

These will be handled in later PRs:

• A failed statement stops the rest of its block. With fn f(a: Missing), let x: u32 = f(1); fails without a new error, and the statements after it in the same block are not analyzed. Other items still are.
• let x: Missing = ... stops its block. let x: Alias = ... already works when Alias is broken.
• A broken use still stops the analysis.
• Fix of Type equality takes exponential time on separately declared alias chains #433

[stringhandler]

in 9518bde

This is pretty difficult to review, can we simplify the logic?
This is clearly vibe coded but is missing the Assisted-by: Claude commit footer

[LesterEvSe]

The main difficulty in this PR comes from using the Never type. The first version was simple, around 300 lines. Then I asked Kyrylo to run an AI review on it, and it found more fundamental problems than I expected. I plan to research this further and try to simplify the code, but I'm not sure the Never type allows it to be as simple as I'd like.

Some of the problems were:

• a crash when casting an enum with a broken payload;
• exponential CPU or memory use on deeply nested aliases, in several variants. This is still a problem: after fixing one case, another one appears.

So I plan to research it more, and then fix and split it into several commits to make it easier to review.

[KyrylR]

ACK 81da432; successfully ran local tests

I see a clear improvement in UX of using the compiler, though the type system becomes even more complex with this PR

I believe we will have to simplify/rewrite it in the future