sanity.system Mauve no longer compatible with recent TimeZone updates

sanity.system Mauve no longer compatible with recent TimeZone updates.
example https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_sanity.system_aarch64_linux_Nightly_testList_0/1064

MauveSingleThrdLoad
MauveSingleInvocLoad

Only affecting jk17, 21 atm, also likely 26 (head) but I didn't test.

I expect this will hit jdk25 when there is an updated version available.
jdk8, 11 may be affected in a future update if the causing change is backported.

Looking through jdk17 changes I noticed the following.
2ea9f00475 8324065: Daylight saving information for `Africa/Casablanca` are incorrect
d66b0f21bc 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values

```
20:29:34 LT 01:29:33.976 - Test failed
20:29:34 LT Failure num. = 1
20:29:34 LT Test number = 4035
20:29:34 LT Test details = 'Mauve[gnu.testlet.java.util.SimpleTimeZone.hashCode]'
20:29:34 LT Suite number = 0
20:29:34 LT Thread number = 0
20:29:34 LT >>> Captured test output >>>
20:29:34 LT PASS: gnu.testlet.java.util.SimpleTimeZone.hashCode (number 0)
20:29:34 LT PASS: gnu.testlet.java.util.SimpleTimeZone.hashCode (number 1)
20:29:34 LT PASS: gnu.testlet.java.util.SimpleTimeZone.hashCode (number 2)
20:29:34 LT FAIL: gnu.testlet.java.util.SimpleTimeZone.hashCode (number 3)
```

Start with the linked Jenkins run and the MauveSingleThrdLoad and MauveSingleInvocLoad failures, especially gnu.testlet.java.util.SimpleTimeZone.hashCode. Review the cited JDK 17 TimeZone changes and reproduce the failure on the affected JDK versions. Done means the affected Mauve tests pass without regressing the reported SimpleTimeZone behavior.

Written by the indexing model from the issue text.