[foreign-memaccess] RFR: 8253063: ScopedAccessError is sometimes thrown spuriously

[Maurizio Cimadamore]

After running the test for shared segment handshake during unrelated work, I noted that the test exhibit two kind of
failure modes:

1. First, the test can sometimes fail with a raw ScopedAccessError
2. More rarely, the test sometimes even crash (this only happens in the vectorized mismatch test)

After some investigation carried out by @fisk, turns out that (2) was caused by the fact that when we exit from
deoptimization we don't check for pending async exception (while we check for regulart ones). This condition was not
triggered in other tests because, it seems, plain unsafe accesses are effectively atomic once intrinisfied - e.g. there
can be no safepoint between check and access. But the vectorized mismatch routine is a biggie Java routine which gets
some initial compilation (by C1) - and this is when the bug hit.

The problem (2) was more difficult to pinpoint - basically, there are some routines in the VM which are hostile w.r.t.
async exceptions - and are marked with the special `JRT_ENTRY_NO_ASYNC` entry. One of those routines happens to be the
one that throws exceptions, and this routine can safepoint too. Now, since the scope memory access can also throw (if
the scope is not alive) it is possible to end up in a situation where we try to install an async exception while the VM
code was already in the middle of installing one. We thought we covered this case by checking for *pending
exceptions* - but the check we had was too weak. After trying with different approaches we agreed to address this more
explicitly - by having the exception code set a flag on the running thread - so that we can precisely determine, when
we do the handshake, as to whether the async exception should be installed or not.

With these fixes, the test passes and no more spurious failures can be observed (I left it running for a long time ;-)).
I've beefed up the test by always having it use max number of available processors, and also by lowering the delay time
associated with the closing thread. The longer the wait, the less frequently transient issues such as (1) can be
observed.

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

Commit messages:
 - Tweak test
 - Add missing fixes
 - More fixes
 - Revert stack depth changes
 - Turn scoped access exception into an error

Changes: https://git.openjdk.java.net/panama-foreign/pull/323/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=323&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253063
  Stats: 109 lines in 14 files changed: 54 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/323.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/323/head:pull/323

PR: https://git.openjdk.java.net/panama-foreign/pull/323