Various Test Target issues in extended.perf openj9 test run on aix

[adamfarley]

Describe the bug
This is a brain-dump bug containing several issues seen in a single aix extended.perf run over the weekend.

These issues will be listed below, in order of occurrence, and issues raised in the correct repositories.

1. There was a stack overflow during execution of the renaissance-als_0 test target, which looks the same as this one. (Will reopen and annotate.)
   Note: the job then correctly executed the next test target to be run, which was renaissance-chi-square_0
2. Later in the job, another test target (renaissance-dec-tree_0) failed with another stack overflow. However, at the end of this test target's section, it strangely declared that renaissance-als_0 had failed.
3. The job then proceeded to execute renaissance-chi-square_0, which had already run earlier. This implies that not only had the test declared the failure of the wrong test target, but some internal error had reset the progression of test targets to the renaissance-als_0 position. Issue raised.
   Note: This pattern continued for the rest of the tests. A random renaissance test target would hit an infrequent stack overflow error, said test target would be incorrectly declared to be renaissance-als_0, and the following test targets to be executed would imply that the progression through the test targets had been reset to the start of renaissance-chi-square_0 again.
4. TRSS correctly identified that there were many instances of renaissance-chi-square_0, but incorrectly declared them to have all failed. Also, the contents of the multiple failures were all from the single instance of renaissance-chi-square_0 which had failed. Issue raised.

To Reproduce
Rerun in Grinder link

Expected behavior
I expect these test targets to execute once in such a scenario, not execute multiple times; resetting their progression every time a failure is encountered.

Screenshots
https://ci.adoptopenjdk.net/job/Test_openjdk11_j9_extended.perf_ppc64_aix/15/

Additional context
While the TRSS failure is perhaps more excusable (garbage in, garbage out), I'm still raising a TRSS issue to see if the TRSS crew feel that it should be more resilient against this particular problem.