RFR: 8375209: Xcheck:jni should check when GC is about to deadlock in JNI critical section

[Aleksey Shipilev]

Related to [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188), and regardless what happens with the implementations, I think we really want to have `-Xcheck:jni` to tell us when we are about to deadlock. This is useful to diagnose the issue in the field.

We used to have this capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344

ZGC never had this check, AFAICS. I am not sure if I put the check in the right place. I believe it is in the right one, as we want to check that Java thread is not blocked waiting for GC driver to respond while being in JNI critical section itself. Current placement works well with the test.

I opted to add the checking at the paths that are really affected by the issue, because it is really about what implementations are doing in this case. But we can also summarily check this in all `CollectedHeap::collect` overrides -- similar to ZGC case -- so that testing with `-Xcheck:jni` with Epsilon/G1/Shenandoah would also cover every other GC that might run into trouble.

Additional testing:
 - [x] New test, 100x repetitions

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

Commit messages:
 - Fix

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

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