[foreign-memaccess] RFR: JDK-8242011: Add support for memory address combinator

[Maurizio Cimadamore]

Following recent changes (see https://github.com/openjdk/panama-foreign/pull/77)which backport some of the goodies in
foreign-abi into foreign-memaccess, this patch brings support for a VarHandle combinator which turns a regular memory
access var handle into a var handle which gets/sets a MemoryAddress (e.g. instead of a long).

This patch also addresses the general problem of the co-existence between combinators in MemoryHandles and the general
var handle combinators in MethodHandles.

This coexistence has always been tricky, because the combinators in MemoryHandles like to create a new 'flattened'
memory access var handle, which provides best possible performances, and also performs certain alignment checks upfront.

However, if a memory access handle is adapted (e.g. the carrier type is changed) this simplistic approach no longer
works, as, by reconstructing the memory access var handle from scratch we will also lose all the adaptations.

The solution is to detect as to wheter the target handle is a "direct" memory access var handle or not (special
provisions are made for the ubiquitous adaptation added on all memory access var handle creation as a workaround for
JDK-8237349). If that's the case, and, if the stride or the offset matches the alignment constraint, then we go the
fast/flattened path and we can adapt by reconstructing the handle from scratch. If any of these two conditions are not
met (there's complex adaption that would be dropped on the floor, or the offset/stride parameter doesn't match with
alignment constraint), then the slow path is taken - the target var handle is kept around and is adapted using the
standard combinator API. This leads to a less performant VarHandle (because, unfortunately, calling addOffset()
currently breaks C2 optimizations), but also guarantees that alignment constraints will be checked in full (this is
because the memory access var handle implementation always checks the alignment of the base address passed to it - only
for the offset part is the alignment check skipped - on the basis that this has already been verified by construction).

The result is that we can lift a lot of the restrictions surrounding the combinators in MemoryHandles; such combinators
can now work on _any_ var handle (provided the var handle has a first coordinate type of type MemoryAddress). Also,
I've lifted the alignment restrictions, since these will either be enforced dynamically (by taking the slow path), or
they won't be enforced because we have already statically proven that the constraints are satisfied (fast path).

I've also took the chance to rename some of the classes surrounding memory access var handles to use the "memory access
var handle" terminology, which is the one that stuck (currently, some classes use the word "address var hande" which is
ambiguous).

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

Commit messages:
 - * Added tests for wrong coordinate types
 - * Fix javadoc
 - * Add combinator to transform numeric carriers into MemoryAddress

Changes: https://git.openjdk.java.net/panama-foreign/pull/84/files
 Webrev: https://webrevs.openjdk.java.net/panama-foreign/84/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-JDK-8242011
  Stats: 2594 lines in 18 files changed: 1390 ins; 1141 del; 63 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/84/head:pull/84

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