On using char-arrays instead of Strings to resprent names

Internally ECJ uses char-arrays to represent names in its parser and AST instead of ordinary Strings.
Examples are
- org.eclipse.jdt.internal.compiler.ISourceElementRequestor
- org.eclipse.jdt.internal.compiler.env.AccessRule

I assume this was done as performance and memory optimization?
While I'm sure this was a good choice back when this was introduced, I wonder if this is still better than using plain Strings Java-17 and later.

The main reasons that make we wonder are
- Compact Strings, introduced in Java-9 with [JEP 254](https://openjdk.org/jeps/254)
- If all characters of a String are Latin-1 characters the String is using just one byte per character instead of two-byte chars.
- ECJ always uses two-byte chars
- In case only Latin-1 names are used, the memory consumption for names could be cut in half
- String Deduplication (in G1) in Java-8 with [JEP 192](https://openjdk.org/jeps/192)
- Supports String deduplication by the JVM respectively the (G1) garbage collector
- Since Java-18 also supported in other GCs: https://malloc.se/blog/zgc-jdk18
- While this not a silver bullet and can have pro's and con's and is not activated by default it could simplify the handling of Strings and make facilities like `DeduplicationUtil` obsolete. The backing arrays of Strings would even be shared with other code running in the same JVM and maybe could reduce duplication even further than today.

- The JVM trusts the constantnes of String's backing array, while it doesn't for char-arrays.
- Quoting from the String implementation:
```
/**
* The value is used for character storage.
*
* @implNote This field is trusted by the VM, and is a subject to
* constant folding if String instance is constant. Overwriting this
* field after construction will cause problems.
*
* Additionally, it is marked with {@link Stable} to trust the contents
* of the array. No other facility in JDK provides this functionality (yet).
* {@link Stable} is safe here, because value is never null.
*/
@Stable
private final byte[] value;
```
- In the recent past the String class was even further optimized, for example in Java-25 the runtime of it's hashCode implementation:
https://inside.java/2025/05/01/strings-just-got-faster/
- The handling of Strings is simpler, which would simplify the code base.

Of course it would be a larger rewrite of significant parts of the code and it is questionable if it's worth the effort.
I mainly interested if any of these points have been considered or evaluated in the recent past with modern JVMs and if you think this could be beneficial?

Start by reviewing the char-array usage in org.eclipse.jdt.internal.compiler.ISourceElementRequestor and org.eclipse.jdt.internal.compiler.env.AccessRule, then trace how these names are represented through the parser and AST. Compare the current approach with Java 17+ String behavior and existing DeduplicationUtil usage; done would require a documented performance evaluation and a maintainer decision on whether a rewrite is worthwhile.

Written by the indexing model from the issue text.