RFR: 8315692: Parallelize gc/stress/TestStressRSetCoarsening.java test

[Soumadipta Roy]

Looking at tier4 tests, gc/stress tests take lots of time per test. For example TestStressRSetCoarsening takes about 33 minutes to runin fastdebug mode in macos arm cpu. This limits effective parallelism of tier4 testing on large machines. We can parallelize its `@run` configs to improve effective parallelism for tier4. Below are some of the observation from before any change, partial parallelization and full parallelization:

* before_release                        : **585.70s user 23.80s system 106% cpu 9:32.16 total**
* before_fastdebug                   : **2033.77s user 30.04s system 105% cpu 32:43.10 total**
* fully-parallelized_fastdebug  : **2246.94s user 36.97s system 135% cpu 28:07.24 total**
* fully-parallelized_release       : **463.52s user 31.54s system 234% cpu 3:31.19 total**
* partially-parallelized_release : **461.15s user 20.88s system 257% cpu 3:06.91 total**

Even though partial parallelization shows better results it has anomaly 33%-50% of the time where the run results are same as before_release. I have runn each of the above combinations multiple times to establish a consistency and fully parallel gives us the most benefit in terms of total time without deviating too much on user and system times.

-------------

Commit messages:
 - 8315692: Parallelize gc/stress/TestStressRSetCoarsening.java test

Changes: https://git.openjdk.org/jdk/pull/15788/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15788&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315692
  Stats: 59 lines in 1 file changed: 56 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15788.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15788/head:pull/15788

PR: https://git.openjdk.org/jdk/pull/15788