Migrate tests for initializing formals

pkg/dev_compiler/test/codegen/language/initializing_formal_final_test.dart

+// Copyright (c) 2016, 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.
+//
+// DartOptions=--initializing-formal-access
+// VMOptions=--initializing-formal-access
+
+import "package:expect/expect.dart";
+
+class A {
+  var x, y;
+  // This should cause a warning because `x` is final when
+  // accessed as an initializing formal.

[vsm, 2016/11/29 23:00:57]

Erik: This should be an error in strong mode, right?  Is there a tracking bug
for that?

[eernst, 2016/11/30 10:22:46]

Right, `dartanalyzer --strong ..` considers assignment to final to be an error.

As far as I can see, we don't have a general solution: There is one test, and it
should be a `CompileTimeError` in some cases and successful in others (because
`dart2js` warnings are not compile-time errors according to `test.py`:
compilation succeeds with an invisible warning, and execution succeeds because
the `noSuchMethod` error caused by the missing setter gets caught and handled).

One thing we can do for now is to make sure we have entries in the status files.
I suppose this is what you already put into 'language_tests.js' (btw, I guess
you can't mark it as a compile-time error there? ..and that it is the correct
error which is emitted?).

I created https://github.com/dart-lang/sdk/issues/27934 to ensure that we check
for dart2js that there is a warning, and that it is the correct warning.

I'm not aware of an issue about this test having a CompileTimeError in strong
mode, but I wouldn't know what to ask for (except for status entries).

+  A(this.x) : y = (() { x = 3; });
+}
+
+main() {
+  A a = new A(2);
+  Expect.equals(a.x, 2);
+  Expect.throws(() => a.y(), (e) => e is NoSuchMethodError);
+}