RFR 8014076: Arrays parallel and serial sorting improvements

[Doug Lea]

>> I don't understand why this is important. Is the general advise not,
>> always use parallelSort unless there is a good reason not to?
>
> That certainly would NOT be my general advise. My general advise is only use
> parallelism to solve a performance problem. Overuse of FJ for non critical tasks
> will just cause contention and an overall loss of performance at the system level.
>

Hoping not to veer too far off track on this.... But
the goal is of course for "parallel" versions of sorting,
stream operations, etc to always have better performance.
Many of the associated changes (like @Contended and smarter
thresholding for parallel sort) represent attempts to get
closer to this goal. There will be cases where it doesn't
hold. In particular, Collection.parallelStream() operations
for very lightweight operations (lambdas) on very few elements
have crummy performance, so rely on Users to not do that.
But the driving sentiment is that in general, users should
get overall throughput improvements for any parallel* method
for which they might reasonably expect it.

Tests of this parallelSort code show that it is almost always
faster than plain sort() unless the array is already nearly sorted.

-Doug