RFR: 8321468: Remove StringUTF16::equals

[Claes Redestad]

https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 

I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658

The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).

In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win (up to -0.2ns/op per `String::equals` on M1; netural on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?

This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

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

Commit messages:
 - Fix and further cleanup RISC
 - Remove StringUTF16::equals

Changes: https://git.openjdk.org/jdk/pull/16995/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321468
  Stats: 138 lines in 14 files changed: 0 ins; 113 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/16995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16995/head:pull/16995

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