RFR: 8313816: Accessing jmethodID might lead to spurious crashes

[Jaroslav Bachorik]

This is a best effort attempt to harmonize the handling of jmethodIDs when the instanceKlass internal structures are being deallocated (eg. due to `ClassLoaderData::free_deallocate_list`).
In all other instances, the jmethodID is NULLed (or set to `_free_method`) before the references Method structures are deallocated. This actually makes possible to query such jmethodIDs without crashing JVM even if the corresponding classes/methods were unloaded.

While it is understandable why JVM can not keep the method metadata around forever it really should be possible to at least assert the validity of a jmethodID without crashing JVM. If nothing else, this makes using the JVMTI functions `GetAllStackTraces` or `GetStackTrace` a risk to use in JVMTI agents - the jmethodids can become invalid the very next moment after the stacktrace is obtained.

-------------

Commit messages:
 - 8313816: Accessing jmethodID might lead to spurious crashes

Changes: https://git.openjdk.org/jdk/pull/15171/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313816
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15171/head:pull/15171

PR: https://git.openjdk.org/jdk/pull/15171