Accessing jmethodID might lead to spurious crashes

In a profiler library (https://github.com/DataDog/java-profiler) we are using JVMTI GetStackTrace to obtain a stacktrace of an allocation which is then tracked for a longer time.

I know that jmethodID is by spec guranteed to be valid only while the declaring class is strongly referenced but that condition is rarely met in practice. There is actually quite a lot of code around making it possible to use a jmethodID even if the declaring class is gone - one would not get any information for such jmethodID but it is not supposed to crash JVM when used.

The crash has the following trace

```
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f3f86175daf, pid=3423779, tid=3423802
#
# JRE version: OpenJDK Runtime Environment Temurin-20.0.1+9 (20.0.1+9) (build 20.0.1+9)
# Java VM: OpenJDK 64-Bit Server VM Temurin-20.0.1+9 (20.0.1+9, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xc46daf] Method::checked_resolve_jmethod_id(_jmethodID*)+0xf
#
# Core dump will be written. Default location: /usr/local/app/core.3423779
#
# JFR recording file will be written. Location: /usr/local/app/hs_err_pid3423779.jfr
#
# If you would like to submit a bug report, please visit:
# https://github.com/adoptium/adoptium-support/issues
#
```

Attaching full log for posterity.