[foreign-memaccess] RFR 8237648: Add support for var handle adaptation

[Maurizio Cimadamore]

Hi,
this patch add support for some VarHandle adapters:

http://cr.openjdk.java.net/~mcimadamore/panama/8237648/

More specifically, the following adaptations are supported:

* filterValue
* insertCoordinates
* filterCoordinates
* collectCoordinates
* permuteCoordinates

This fixes an expressiveness mismatch between VarHandle and 
MethodHandles, as one could adapt MethodHandles, but cannot adapt 
VarHandles (the only way to do that is to map a VarHandle to a 
MethodHandle - using an AccessMode - and then use the MethodHandle).

To achieve this, only minimal surgery to j.l.invoke classes was 
required: the basic idea is to introduce a new class of VarHandle, 
namely IndirectVarHandle, which is merely an aggregate of a bunch of 
method handles, one per supported access modes. This means that we have 
now the ability to take apart an existing var handle into its MH 
components, adapt such components and repackage them into a brand new 
VarHandle.

To save unnecessary bytecode spinning, the component MethodHandles of an 
indirect VarHandle are only created on-demand - that is, if you only 
ever use the GET access mode - the machinery will not create the method 
handles for all the access modes which could be in principle be 
supported by the new var handle.

Since adapting a VarHandle might introduce changes in some of the 
coordinate types, I've disabled the VarHandleGuards fastpath for 
indirect handles, as the fast path does an invokeBasic and it skips any 
kind of type adaptation. While invokeBasic will detect e.g. a long vs. 
int mismatch, it does not detect (by design) a String vs. Runnable 
mismatch, so it is preferrable for indirect handles to always have an 
asType() adaptation. If the client is doing things "by the books" and 
using exact types in the VarHandle call, the asType() will do nothing 
and performances will not be negatively affected.

I also needed to tweak lambda form generation for var handles a bit, to 
obtain the direct var handle associated with an indirect handle before 
calling the linker method (otherwise we might end up the underlying 
VarHandle routine with the wrong VarHandle type).

I think overall, this implementation strategy proved to be flexible and 
relatively efficient - we can easily add as many adapters as we want, 
since we can build on the already rich MethodHandle combinator API.

Cheers
Maurizio