GeezerVison

This PR fixes #6346 by implementing two changes:

• The type of a variable declared in a for-in statement is implicitly string (previously it was any).
• When an object with a numeric index signature of type T (such as an array) is indexed by a for-in variable of a containing for-in statement for an object with a numeric index signature and without a string index signature (again such as an array), the value produced is of type T.

An example:

var a: MyObject[];
for (var x in a) {   // Type of x is implicitly string
    var obj = a[x];  // Type of obj is MyObject
}

With this PR, the type of x is now string and the type of obj is MyObject because the array is indexed with a for-in variable for an array (and thus the for-in variable is known to contain a numeric string). Had the array been indexed with any other string expression, the type of obj would be any because the string could be the name of a property or method (e.g. "length" or "push").

For historical reasons we have used type any for for-in variables even though the iterated values are always strings. The reason we used type any is that when an array is indexed with an expression of type any or number we produce a value of the array element type, and thus the example above produces the correct type for obj. However, with the second new rule above, indexing with an expression of type string can now also produce a value of the array element type if the expression is a for-in variable for an array.

The use of type any was never a great solution, in particular because the any is "silent" and not caught by the -noImplicitAny flag. Furthermore, with the introduction of the new for-of statement in ES2015 it got worse. Consider:

var a: MyObject[];
for (var x in a) {       // Accidentally used for-in instead of for-of
    x.myObjectMethod();  // Reports an error now, but didn't before
}

This PR is a breaking change for certain (suspicious) constructs. For example:

var a: MyObject[];
for (var x in a) {
    if (x == 1) {  // Previously ok, now an error
        // ...
    }
}

Previously, the static type of x was of type any. Thus, even though x contains a string it could be compared to a numeric literal (at run-time this coerces the string operand to a number and then compares that to the numeric operand). This is one of the not so good parts of JavaScript. Mixing of strings and numbers only work for some operators and are a source of many a surprising bug (for example, it doesn't work with the === operator, and + concatenates string values instead of adding the numeric values).