fix corelib_2/iterable_to_set_test to reflect strong mode runtime checks

tests/corelib_2/iterable_to_set_test.dart

Index: tests/corelib_2/iterable_to_set_test.dart
diff --git a/tests/corelib_2/iterable_to_set_test.dart b/tests/corelib_2/iterable_to_set_test.dart
index b0056ffe13b1d6623d5256cda79693f3c71e818b..4a92c2cd5ae05cf0a26f25eeabbe37123d58fa48 100644
--- a/tests/corelib_2/iterable_to_set_test.dart
+++ b/tests/corelib_2/iterable_to_set_test.dart
@@ -45,9 +45,11 @@ main() {
   Expect.isFalse(setStrCopy is Set<int>);
   Expect.isFalse(identical(setStrCopy, set2));
 
-  setCopy = set3.toSet();
-  Expect.setEquals(set3, setCopy);
-  Expect.isTrue(setCopy is Set<String>);
-  Expect.isTrue(setCopy is Set<int>);
-  Expect.isFalse(identical(setCopy, set3));
+  {
+    var setCopy = set3.toSet();

[Jennifer Messerly, 2017/08/04 23:33:11]

the setCopy local in the outer scope has inferred type Set<int>, so this
implicit downcast was failing.

[Bob Nystrom, 2017/08/04 23:45:41]

In other tests where we've had to split a reused variable, we tend to just
rename instead of introducing a block. How about "set3Copy"?

[Jennifer Messerly, 2017/08/05 00:05:43]

Done.

+    Expect.setEquals(set3, setCopy);
+    Expect.isFalse(setCopy is Set<String>);

[Jennifer Messerly, 2017/08/04 23:33:11]

these should be false, not true.

[Bob Nystrom, 2017/08/04 23:45:41]

Should we add an isTrue check for is Set<dynamic>?

[Jennifer Messerly, 2017/08/05 00:05:43]

Done.

+    Expect.isFalse(setCopy is Set<int>);
+    Expect.isFalse(identical(setCopy, set3));
+  }
 }