Validate u1 count bound in INVOKEINTERFACE and MULTIANEWARRAY

[rootvector2]

The count operand of invokeinterface and the dimensions operand of multianewarray are each a u1 (1-255), but INVOKEINTERFACE(int, int) and MULTIANEWARRAY(int, short) only check the lower bound (nargs < 1 / dimensions < 1) while their dump() writes the field with out.writeByte(...). A value in 256-32767 is accepted and returned by getCount()/getDimensions(), but truncated to its low 8 bits on dump, so the emitted instruction carries a different count than requested (e.g. 260 is written as 4). Found while sweeping the generation-side writeByte sites after #506 fixed the u2 index setters. Adds the matching > Const.MAX_BYTE guard to both constructors; IINC/RET/LDC already pick a wider form so they are unaffected.

• 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. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hello @rootvector2
Please skip the new test class into 2: One for each main class modified.

[rootvector2]

Done. Split it into one class per instruction: the MULTIANEWARRAY tests moved into the existing MULTIANEWARRAYTest and the INVOKEINTERFACE tests are now in a new INVOKEINTERFACETest; CountBoundsTest is gone.