[dart2js] Pass type arguments as tuples or useful interface type

[rakudrama]

This issue details on an optimization listed in #37715.

Pass tuples

Part of the original 'new rti' design was to pass multiple type arguments as a tuple. This has not yet been implemented, but would clean up a lot of overhead in creating types for the Map implementations.

Pass a derived type

Often the type parameter (or tuple) is used in a derived type that is a function only of the type parameter. Provided the derived type is tuple-like (e.g. an interface type), the derived type can be passed instead of a tuple. This is a common case in generative constructor factories:

class Foo<T> {
  Foo();
}
main() {
  print(Foo<int>());
}

Foo: function Foo($ti) { this.$ti = $ti },
Foo$($T) { return new Foo($T.eval("Foo<1>")) }
main() {
  P.print(Foo$(type$.int));
}

By changing the calling convention so that the generative constructor factory Foo$ takes a Foo<T> as the type parameter, the eval is pushed to the call site where it can be fused with the operation that used to generate T. In this example it becomes a ground type term.

Foo: function Foo($ti) { this.$ti = $ti },
Foo$($Foo_T) { return new Foo($Foo_T)) }
main() {
  P.print(Foo$(type$.Foo_int));
}

We can do this without much analysis for generative constructor factories. The analysis for factory constructors calls is a little more complicated, as the different paths need to be consistent. We would like to be able to pass in JSArray<int> to the List<int>.of factory constructor. All the methods involved are static, so it should be possible to do the analysis on a subset of the call graph.
An experiment for passing in JSArray<E> to List constructors showed up to 20% gains for small lists where the type becomes a ground term in the caller.

Constructor tear-offs are implemented by tear-offs of static methods that call the constructor. This is convenient since the directly called entry (the original) and an indirectly called entry (the static method) can have different calling conventions with respect to the type arguments.