Kernel representation of forwarding stubs is very inconvenient

[sjindel-google]

Because they require special treatment, backends have to "pattern-match" against their bodies and compile them differently from other functions.

A representation more akin to redirecting factory constructors would make implementation easier.

[stereotype441]

This sounds like a nice way to address #31027 as well

[stereotype441]

Note to whoever is implementing this: there are two things one might mean by the "target" of a forwarding stub:

1. The interface target that would have been used had the forwarding stub not been present. I call this the "interface target" of the forwarding stub. Error messages based on static type analysis should use this target. The analyzer should use this target for "go to definition".
2. The method that the forwarding stub forwards to at runtime. I call this the "super target" of the forwarding stub, since it is always in the superclass chain. The VM, dart2js, and DDC should use this target to determine which method the forwarding stub should invoke at runtime, and which types should be used for type checking.

Consider:

class A {
  void f(int x) { ... }
}
abstract class I {
  void f(covariant Object x);
}
class B extends A implements I {}

B will contain a forwarding stub for f. Its interface target is I::f. Its super target is A::f.

The target the VM cares about is the super target, and we already have a different bug about the interface target (#31519). So let's say that for the purpose of this bug, the representation we need is one that makes it easy for the back end to find the super target.