vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception

# Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S24665/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/19ada292-095c-4a96-88e4-8469ef3802b1/runs/bbbae971-d40c-4e18-8cd5-ce41dd8a279d/workspace/open/src/hotspot/share/utilities/exceptions.cpp:366), pid=2573427, tid=2573910
# assert(incoming_exception.is_null()) failed: Pending exception while throwing java/lang/ClassFormatError Duplicate method name "proc2" with signature "(I)V" in class file javasoft/sqe/tests/vm/concepts/methods/methods001/methods00101m1/methods00101m11n
#
# JRE version: Java(TM) SE Runtime Environment (21.0+16) (fastdebug build 21-ea+16-LTS-1267)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-ea+16-LTS-1267, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xd43241] Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x221

This appears to be caused by JDK-8304069. That change moved some calls to classfile_parse_error from the end of the calling function into the loop where the detection is occurring. But the calls still pass THREAD as the final argument. That will record a pending exception, but not terminate the loop. So if there are multiple problems in the class file, instead of throwing an exception reporting the first one, we get this pending exception crash. I think the in-loop calls to classfile_parse_error should be be using CHECK as the last argument rather than THREAD.