Loose end: spliterator() and stream() methods on Iterable

[Brian Goetz]

This is one that everyone seems in agreement with (in theory) but which 
we never get to convergence on.  Given how the API has shaken out, it 
seems sensible to:

  - Add spliterator() to Iterator, with a default implementation of

    return Spliterators.spliteratorUnknownSize(iterator(), 0)

  - Move the existing stream() and parallelStream() methods up from 
Collection to Iterable, as is (they are implemented entirely in terms of 
spliterator() and public factories)


When this last came up, there was concern that the spec of 
Iterable.stream() would be exactly as fuzzy as the spec of 
Iterable.iterator().  I think the best we can do is add an 
implementation note that if iterator() indeed gives you a fresh iterator 
every time, then stream() gives you a fresh stream every time, and 
otherwise unpredictable results will follow.  It would be nice to 
further note that subtypes of Collection are better behaved, but sadly 
the spec for iterator() in Collection is no better than in Iterator!  We 
can further add a "recommendation" to Iterable.iterator() to suggest 
that Iterable implementations are encouraged to do this, but otherwise I 
think this ship has sailed.