Add negative verifier tests for remaining array load/store component type checks

[rootvector2]

Follow-up to #522, adding the negative tests discussed there. TestArrayAccess05 and TestArrayAccess06 only cover iaload and caload, so the component-type checks for the remaining array load/store instructions in InstConstraintVisitor had no negative coverage.

Adds a parameterized TestArrayAccess07Creator that applies a given array access instruction to an array whose component type does not match (castore on an int[], iastore on a char[], aaload on an int[], and so on), plus a parameterized test asserting structural verification rejects each of aaload, aastore, baload, bastore, castore, daload, dastore, faload, fastore, iastore, laload, lastore, saload and sastore. The aastore case stores null into an int[], which hits the element-type branch rather than the value-type branch already covered by the TestArrayAccess04* family. I checked each case fails in Pass3b on the component-type constraint specifically, not in an earlier pass.

One creator handles all fourteen cases instead of fourteen creator subclasses; TestCreator.getClassName becomes protected so the creator can name the generated class after the instruction.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.