Add tests for generic methods in strong mode

tests/language_strong/generic_methods_dynamic_test.dart

+// Copyright (c) 2017, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+library generic_methods_dynamic_test;
+
+import "package:expect/expect.dart";
+
+class A {}
+
+class B {}
+
+class C {
+  T fun<T>(T t) => t;
+}
+
+main() {
+  B b = new B();
+  C c = new C();
+  dynamic obj = c;
+

[karlklose, 2017/03/09 09:17:00]

Use multi-tests?

c.fun<A>(b);  /// 01: compile-time error

[Dmitry Stefantsov, 2017/03/10 13:21:53]

Thanks! I put the checks for both compile-type error and runtime error then.

+  Expect.throws(() => obj.fun<A>(b), (e) => e is TypeError);

[karlklose, 2017/03/09 09:17:00]

() => obj.fun<A>(b);  /// 02: runtime error

[eernst, 2017/03/09 14:55:02]

This tests one of the cases I mentioned above in
generic_methods_boundaries_test.dart (that the actual type argument is taken
into account when checking arguments to a dynamic invocation of a generic
function), so we might as well do it here and drop it up there.

It would seem natural to have the positive dynamic case as well: `fun<B>(b)`
should succeed and return b.

And a case where the type argument is used in a non-trivial manner: `List<T>
fun2<T>(Iterable<T> t) => <T>[t.first];`, such that the dynamic check must
discover that the type argument is B and the value argument must then be an
Iterable<B>.

[Dmitry Stefantsov, 2017/03/10 13:21:53]

Probably, it should be 'obj.fun<A>(b);', otherwise it's just an expression of a
closure type that isn't called anywhere and doesn't produce any runtime errors.

[Dmitry Stefantsov, 2017/03/10 13:21:53]

Done.
Agreed and done.
Agreed and done.

+}