JEP draft: refactor per-instance metadata to be separate from ClassInfo metadata

InstanceKlass today serves triple duty:

1. It records the contents of a loaded classfile plus resolution states.
2. It represents a "live type" (a subtype of Klass) in the JVM bookkeeping.
3. It is the pointer in the header of an instance of a heap-allocated object.

All of these duties add to the complexity of InstanceKlass. Let's split it up into two or three modules:

1. ClassFile (or ClassFileInfo, ClassFileStructuure, etc.) should be a loaded classfile, with an associated ConstantPool holding constants and their resolution states. Much of today's current contents of InstanceKlass should be renamed into this new class.

2. InstanceKlass should become an abstract API with one implementation called ClassFileKlass, which contains a pointer to a ClassFile. These types should be "hollowed out", and only retain methods which seem directly applicable to a JVM bookkeeping over types. That includes methods shared with Klass, arrayKlass, etc.

3. The object header can contain a direct InstanceKlass pointer, just as today. It can be encoded or decoded in the case of compression (or other tricks in the future).

When we start implementing specialization, a distinction will arise between three things:

1. A plain class.
2. A parametric class (what we used to call a "template class")
3. A species of a parametric class.

Clearly cases 1 and 2 have a direct one-to-one relation to a ClassFile structure, and case 3 does not. Instead, case 3 is in a many-to-one relation to case 2. This suggests the following types:

0. InstanceKlass is abstract (we wanted to do this in the first place)
1. ClassFileKlass <: InstanceKlass (today's code, renamed)
2. parametric paraphernalia added to ClassInfo
3. SpeciesKlass <: InstanceKlass points to ClassInfo and parameter binding stuff

The parameter binding stuff needs to include constant pool states for parametric constants: These are in a many-to-one relation to the original ClassFile and ConstantPool. We'll need a type for that, to work underneath the proposed java.lang.invoke.ParameterBinding mirror.

Currently, a Method knows where it belongs to because it has a pointer to a constant pool, which then is in one-to-one relation to the ClassFile info around the method--all very cozy. For specialized methods, this design can remain, since the parameter binding for a specialized method call is associated with a stack frame, rather than a method itself.

See also: http://mail.openjdk.java.net/pipermail/valhalla-dev/2020-October/008083.html