Setting of UNORDERED on concurrent collectors

[Brian Goetz]

Now that we've removed collectUnordered in favor of a more general 
unordered() op, we should consider what should be the default behavior for:

   orderedStream.collect(groupingByConcurrent(f))

Currently, the collect-to-ConcurrentMap collectors are *not* defined as 
UNORDERED.  Which means, if the stream is ordered, we will attempt to do 
an ordered collection anyway, which is incompatible with concurrent 
collection, and we will do the plain old partition-and-merge with 
ConcurrentMap.

Here, we have competing evidence for the user intent.  On the one hand, 
the stream is ordered, and the user could have chosen unordered.  On the 
other, the user has asked for concurrent grouping.  Its not 100% obvious 
which should win.

On the other hand, ordered map collections are so awful that they will 
almost certainly be unhappy with the performance if they forget to say 
unordered here in the parallel case (and it makes no difference in the 
sequential case.)  So I'm inclined to make groupingByConcurrent / 
toConcurrentMap be UNORDERED collections.