RFR: 8173912: [JVMCI] fix memory overhead of JVMCI

[Doug Simon]

Please review this change that fixes footprint issues in JVMCI by reducing unnecessary memory allocation
and reducing the total set of permanently live objects by an order of magnitude. The changes described
below have been tested with JVMCI client Graal.

HotSpotVMConfigStore
====================

HotSpotVMConfigStore communicates VM configuration info from the native VM code to the Java parts of JVMCI.
This change reduces the amount of data crossing this boundary significantly:
 - Only the VM flags currently used by JVMCI and Graal are communicated. A VM call is added as a
   fallback for accessing the other flags. A test for the new getFlagValue() VM call is included.
 - The Java object values encoding the info are canonicalized in the VM using a ResourceHashtable.
 - Only the VM type sizes used by JVMCI and Graal are communicated.
The above changes result in reducing the memory overhead of HotSpotVMConfigStore from 904,210 to 364,742 bytes.

HotSpotResolvedObjectTypeImpl
=============================

This change removes or slims down a number of caches for the fields and methods in HotSpotResolvedObjectTypeImpl.

For method caches, a lighter weight array is now used that only falls back to a HashMap when more than 8 methods
are requested for a given type. During a JVMCI bootstrap (i.e. -XX:+BootstrapJVMCI), of 8024 HotSpotResolvedObjectTypeImpl
objects created, 4156 types never have a method requested, 3353 use the array-based cache and 253 fall back to
the HashMap.

For fields, caching has been removed entirely since HotSpotResolvedJavaFieldImpl is such a lightweight data
structure that creating a new one every time doesn’t matter. In addition, changes described below made it lighter
than it previously was.

Method and field names
======================

The names of HotSpotResolvedJavaFieldImpl are rarely needed, mostly only being used in debugging code. In a JVMCI bootstrap
only 1490 of 154699 fields have their names accessed. As such, the HotSpotResolvedJavaFieldImpl.name field has been removed
and the name is now retrieved by a VM call. Also, since fields are no longer cached, the HotSpotResolvedJavaFieldImpl.toJavaCache
field storing the java.lang.reflect.Field mirror has been removed. This mirror is only ever accessed by debug code.

The names of most HotSpotResolvedJavaMethodImpl are also rarely needed. In a JVMCI bootstrap only 3259 of 11267 methods
have their names accessed. However, if a name is accessed once for a method, it is typically accessed numerous times. As
such, the name is now stored in a lazily created cache. In addition, the isConstructor() and isClassInitializer() methods
have been changed to directly compare the raw Symbol* holding the name with the vmSymbols::object_initializer_name() and
vmSymbols::class_initializer_name() values respectively. This further reduces the names created in a bootstrap to ~2000.

Clean up
========

There’s a small clean up in .mx.jvmci/mx_jvmci.py that removes unused functionality for zipping up the JDK
after running `make images`.

https://bugs.openjdk.java.net/browse/JDK-8173912
http://cr.openjdk.java.net/~dnsimon/8173912/webrev/

-Doug