unordered()

[Brian Goetz]

So, the move to a more explicit choice of merging or concurrent 
tabulation also reduces (heh) the need for unordered(), though it does 
not eliminate it completely.  (Limit, cancelation, and duplicate removal 
all have optimized versions if encounter order is not significant.)

Kevin pointed out that .unordered() is pretty easy to miss, and people 
will not know that they don't know about it.  One possible is to make it 
more explicit at one end of the pipeline or the other (the only 
operation that is order-injecting is sorted(), and presumably if you are 
sorting you really care about encounter order for the downstream ops, 
otherwise the sort was a waste of time.)

The proposed tabulator / reducer stuff makes the order-sensitivity clear 
at the tail end, which is a good place to put it -- the user should know 
whether a reduce or a forEach is what they want -- if not the user, who? 
  (Only the user knows whether he cares about order or not, and knows 
whether his combination functions are commutative or not.)  The other 
less-ignorable place to put an ordering opt-out is at the head; we could 
make things more clear with adding

   .parallelUnorderedStream()
alongside
   .stream()
and
   .parallelStream()

The obvious implementation of parallelUnorderdStream is:

     default Stream<E> parallelStream() {
         return stream().unordered();
     }

which is also the most efficient place to put the .unordered (at the 
head.)