A number of core classes in Valhalla are converted to value classes.
When preview is enabled class loading and all other access to the classes needs to find and return the alternate classes.

The original prototype mechanism leveraged the module patching system.
Moving the replacement classes to reside in jimage will provide more consistent access.

The layout in the jimage file will be:
1. Preview resources will only exist per module.
2. Preview resources for '/modules/<module>/<path>' will be in '/modules/<module>/META-INF/preview/<path>'

When "preview mode" is enabled (typically by use of '--enable-preview'):
1. Preview resources will overlay non-preview resources (by path matching).
2. The '/packages/xxx' directory (when used) will correctly reflect any new packages inferred by preview resources.
3. [IMPORTANT] Non preview resources, will still be returned EVEN IF they were originally related to replaced resources
    (e.g. nested/inner class defined by a non-preview class, but no longer defined by the preview version).
    This could be resolved by checking for preview versions of the implied owning class, but this was determined to be
    unnecessary (for now). It is more work and still cannot address resource files (where "ownership" cannot be inferred).
    
However, regardless of whether "preview mode" is enabled or not:
4: Neither the directory '/modules/<module>/META-INF/preview' nor any of its contents will ever be available to a user
   by any "normal" mechanism within a Java runtime. Class or resource lookup will fail for anything in this space (as if
   the resource was not present), and this directory will not appear in the JRT file system at any time.
   Only build tools such as jlink or similar will be able to observe content in this namespace.
    
There are multiple places in the JDK and tools where this needs to be addressed:
* C++ class loaders
* JRT file system and associated image reader classes
* The "exploded image" mechanism
* Possibly the ctSym symbol file lookup (JDK-8 compilation)

Care must be taken when determining exactly when preview mode is to be enabled.
Specifically, this work violates some unstated assumptions which have previously existed in the JDK:
* There is a single view of classes/resources for the "default runtime" which can be expressed in a singleton instance.
* Compiling for a target which just happens to reference the same JDK as the compiler, can just use the same resources.