Java uses of bootstrap methods for indy and condy, and is likely to
further modify them.  The code in the JVM and JDK needs consolidation.

The JDK support code for BSMs is hard to read and maintain.  Let's
clean it up and simplify it.  There should be a single BootstrapInfo
struct in the JVM which expresses all BSM-related state, similar to
the CallInfo and LinkInfo structs.

The handshake from the JVM to JDK code is complicated and
ill-documented.  Let's simplify that also.  If we regularize all BSM
paths to use BootstrapCallInfo only, we will lose no generality or
performance, and make the code easier to maintain and evolve.
It will also be easier to evolve the JVM specification, with regard
to bootstrap methods, if new behaviors can be expressed mainly
at the JDK level, as the behaviors of the JDK processing BSCI
instances.

As part of this, let's remove unused JVM paths and data fields.  For
example, the method_type field associated with the appendix field of
an indy or method handle call is unused and just adds complexity and
footprint.  Also, while we are simplifying the CP support for such
call sites, we can rename them to be about BSMs rather than about indy
and condy, and we can share more indy and condy code in common.

Let's also move bootstrap argument processing from MethodHandleNatives
to the pre-existing (low-level, privileged) ConstantPool class.  That
also unlocks the capability for BSMs to gain direct access to CP
structures.

Remove ConstantGroup; it was a bad idea.  Instead, merge argument
access into BootstrapCallInfo, back-ending to ConstantPool.  Of
course, the JVM should continue to pre-load argument lists.

Adjust BSM argument access: remove copyArguments in favor of reusing
the List.toArray protocol.  Add an argumentRef API for direct access
to BSM arguments in symbolic form.  Also, add invocationTypeRef to
support pre-resolved types (method and field), so that non-resolvable
types can be processed.

The Amber work has uncovered the need for new BSM modes which can omit
metadata (lookup, name, type).  Implement this as an open-ended
"expression mode" to go with the legacy "push mode" and universal
"BootstrapCallInfo" modes; this gives it some room to grow in the
future.

About half of this work is in the JVM, half in the lower levels of the JDK.
New Java APIs can be rolled out over time, but need not be public at first.

User-visible "expression mode" BSMs will be a feature of this work.

Here's a prototype of these changes:
  http://cr.openjdk.java.net/~jrose/jvm/JDK-8210685/