Better exhaustiveness handling for sealed subtypes

[FMorschel]

We currently have our exhaustiveness missing cases defined at pkg/_fe_analyzer_shared/lib/src/exhaustiveness/exhaustive.dart.

Say, for this dummy example, which is a piece of snapshot from our current analyzer ast:

sealed class FormalParameter {}
sealed class NormalFormalParameter implements FormalParameter {}
// Note this is not `sealed` because it is `final`
abstract final class SimpleFormalParameter implements NormalFormalParameter {}
// Again, only final, but this closes the hierarchy
final class SimpleFormalParameterImpl extends NormalFormalParameterImpl implements SimpleFormalParameter {}

If we ask for Add missing switch case fix (inside the analyzer package):

import 'package:analyzer/dart/ast/ast.dart';

void f(FormalParameter p) {
  switch (p) {
  }
}

We get this output:

import 'package:analyzer/dart/ast/ast.dart';

void f(FormalParameter p) {
  switch (p) {
    // TODO: Handle this case.
    SimpleFormalParameter => throw UnimplementedError(),
    // TODO: Handle this case.
    SimpleFormalParameterImpl => throw UnimplementedError(),
  }
}

From @bwilkerson's #60531 (comment):

[...] including the Impl classes does seem like a bug.

That code looks for all subtypes of sealed classes. In the case above, both SimpleFormalParameter and SimpleFormalParameterImpl. I think is the correct fix here would be to check if another parent type is present in the list, then to ignore this type, and remove previously added subtypes if we find a parent type. Not entirely sure if any ordering here would suffice to handle both checks.

[lrhn]

Agree.

Both classes have NormalFormalParameter as declared superinterface, but one of them is dominated by the other.

The exhausting subtypes of a sealed type, Foo, should be the proper subtypes of Foo that are not also proper subtypes of another proper subtype of Foo.