infer null from context, this avoids bottom being introduced

pkg/analyzer/test/generated/strong_mode_test.dart

Index: pkg/analyzer/test/generated/strong_mode_test.dart
diff --git a/pkg/analyzer/test/generated/strong_mode_test.dart b/pkg/analyzer/test/generated/strong_mode_test.dart
index 75f4ea97f808527b2b86d832394b195d056a5707..67d6deb565b3bcf3dacf9633ad077bb6e66e2d69 100644
--- a/pkg/analyzer/test/generated/strong_mode_test.dart
+++ b/pkg/analyzer/test/generated/strong_mode_test.dart
@@ -2046,7 +2046,7 @@ main() {
 }
 ''';
     resolveTestUnit(code);
-    expectInitializerType('foo', 'int', isNull);
+    expectInitializerType('foo', 'dynamic', isNull);

[Jennifer Messerly, 2016/08/04 13:10:16]

This case is really unfortunate and makes me doubtful of the merits of this CL.
To some extent, it may be avoidable with null aware ops, but not always.

I suppose we could add some logic for ternary ops when one of the branches is
null? Or is that just papering over the problem.

[Leaf, 2016/08/04 23:52:55]

Yeah, I think this will cause problems.  I think it will show up in other places
that LUB is used as well.  I think there are ways we could tackle this, but not
sure it's worth it right now.

[Jennifer Messerly, 2016/08/05 13:46:36]

Yeah, definitely doesn't seem right at the moment.

Another thought here is define a type for `null` (maybe Null?), and have it be
subtype of other nullable types. essentially LUB(Null, T) becomes T in our
current system (and could be extended once we have non-nullable types).

But that's getting a little out of the scope of this change, so going to close
this one :)

   }
 
   void test_ternaryOperator_null_right() {
@@ -2056,7 +2056,7 @@ main() {
 }
 ''';
     resolveTestUnit(code);
-    expectInitializerType('foo', 'int', isNull);
+    expectInitializerType('foo', 'dynamic', isNull);
   }
 }