Implements RFC ponylang#48. For full details see
https://github.com/ponylang/rfcs/blob/master/text/0048-change-String-join-to-take-iterable.md.

The Iterator interface places fewer requirements on the implementation
when compared to ReadSeq. The ReadSeq requires that your implementation
have random access (apply(USize): T), have a known size (size(): USize)
and support sequential (ordered) access by returning an Iterator from
the values() function. Where as the Iterator only requires that the
implementation have sequential access, so is a subset of the
functionality if ReadSeq. There are a number of cases where supporting
an Iterator interface rather than ReadSeq would be desirable. Supporting
a database cursor or a stream from a network service are two that come
immediately to mind.

The other case that crops up is compatibility with other parts of the
pony stdlib. The itertools package which provides a number of useful
functions over unbounded streams of data, similar java streams library.
The specific case I was looking at taking a stream of data, mapping a
transformation over it, then joining the result. Itertools was the only
part of the library that supported that sort of functionality, but
didn't provide a join or reduce function. I found the join function on
String, which required that the call supply a ReadSeq, but internally
only ever needs in Iterator. It seems a simple and obvious change to
make the join function take an Iterator making it a more useful
function. It is trivial to convert from a ReadSeq to an Iterator,
however it is more difficult and has a higher cost to convert in the
other direction.