Concurrent / unordered collection

[Brian Goetz]

We've had some improvements in the model for managing ordering, so its 
time to take a look at whether these can flow into Collector as well.

  - There is now an .unordered() operation, and we removed the 
special-purpose .collectUnordered().

  - Terminal operations can have flags/characteristics just like 
intermediate operations.  The allowable flags for a terminal operation 
are ORDERED/NOT_ORDERED and SHORT_CIRCUIT.  The unordered status can 
back-propagate from a terminal up the pipeline:

   stream.distinct().forEach(...)

In the above, ordinarily distinct would be constrained to encounter 
order.  But, because we know there is an unordered forEach operation 
coming downstream, we can back-propagate UNORDERED up the chain, 
enabling the more efficient unordered version of distinct().

  - The Collector API has been enhanced with characteristic flags, just 
like Spliterator and Stream.  Defined characteristics include CONCURRENT 
and UNORDERED.  UNORDERED-ness of a Collector flows into the terminal 
flags of a collect() operation.  So, for example, toSet() is an 
unordered collector.

Until now, you only got a concurrent reduction when BOTH of the 
following were true:
  - the Collector is CONCURRENT
  - the source is unordered

This was because a concurrent collection fundamentally interferes with 
encounter order.  So if a user did:
   stream.collect(groupingByConcurrent())

they would NOT get a concurrent collection because the stream is ordered.

But, I think this may be surprising to users.  Now that a Collector can 
indicate that it is UNORDERED, I think we should consider making the 
concurrent-map collectors UNORDERED.  So if a user says:

   stream.collect(groupingByConcurrent())

he truly gets a concurrent collection.  If he is surprised that this is 
an unorderd collection, it is an opportunity to learn more about 
ordering.  But I think this is more consistent with user expectations 
and we can now more easily represent this in the API.