Adjusted spec of For-In to insist on Iterable

[eernstg]

The specification of a for-in statement used to rely on having an iterator member on the iterable, and on being able to do moveNext() and current on the returned object. With this change, we insist that the iterable must actually have type Iterable<T> for some T.

Note that deployed code already requires this (verified with dart and dart2js), and it is already specified for an asynchronous for-in that it is a dynamic error for the iterable to not be a Stream. So this is more consistent, not breaking in practice, and more strongly typed.

[lrhn]

The advantage of this change is that we can use Iterable<T> as context type for the iterable expression e of for (T x in e). We currently can't because it might not be an iterable.

My guess is that we are already doing this, which is why implementations fail when it's not actually an iterable.
That's also supported by for (var x in {}); not throwing. By the specification, this should be trying to iterate a map, but since it succeeds, we are obviously iterating a set. That means the context type must already be an iterable type.