RFR: 8324492: Remove Atomic support for OopHandle

[Kim Barrett]

Please review this change to the lazy initialization of the MemoryManager
object and the associated MemoryPool objects.

They previously used an atomic access to the respective OopHandle member
holding the associated Java object as the is-initialized sentinal, testing
whether the handle was empty or had an associated OopStorage entry. When
empty, initialization was performed using a lock to prevent races.

Now they use a separate atomic is-initialized flag as the sentinal.

As a result, the support for atomic access to an OopHandle's underlying handle
(via a translator) is no longer needed and is removed.

While there, I moved the allocation of the associated OopStorage entries out
from under the Management_lock.

Testing: mach5 tier1

A couple of notes for reviewers.

Once initialized with a Java object recorded in the associated OopHandle, the
OopHandle and the value recorded therein is never changed.

The old is-initialized check makes use of OopHandle::resolve returning null if
either the handle is empty (has no OopStorage entry yet) or the OopStorage
entry contains null. The latter never happens in this case.

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

Commit messages:
 - remove unused OopHandle translator
 - MemoryPool doesn't use atomics on OopHandle
 - MemoryManager doesn't use atomics on OopHandle

Changes: https://git.openjdk.org/jdk/pull/17533/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17533&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324492
  Stats: 101 lines in 5 files changed: 24 ins; 14 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/17533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17533/head:pull/17533

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