Review request on the optional modules support

[Mandy Chung]

An update on the optional module support [1].

Webrev:
    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/optional-modules.00/

The note has been updated to include the open questions raised in
the discussion.
    http://openjdk.java.net/projects/jigsaw/doc/topics/optional.html

There is an open question whether the isModulePresent method should
take a version-range argument or other alternative for an application
to support different versions of modules with incompatible change (see [2]).

I propose to get this prototype in the jigsaw repository first
and address the open question next as we would need to get the use
cases to determine what the right API for it.

Summary of Changes:
1. A new @RequireOptionalModule annotation is defined to
    indicate that the annotated type requires the optional module
    to be present when it's referenced; otherwise,
    ModuleNotPresentException would be thrown.

    See java.util.Properties.loadFromXML and other examples in the JDK.

2. Two new methods are added in the java.lang.reflect.Module class
    to test if a module has been resolved and linked with this
    module's context.

    The requireModulePresent(String mn) method checks if
    the given module is present; if not, it throws ModuleNotPresentException.

    isModulePresent(String mn) simply returns true/false
    and it can be used for the fall-back cases if an optioanl module
    is not present.

3. Class.getModule() is modified to lazily set the Module for
    a system class loaded by the VM bootstrap null loader.

    The VM loads the primordial classes directly in the VM
    and also other system classes when the caller is loaded
    by null class loader without calling the library. The
    Class's module field is null in that case.  The Loader
    class is refactored to support the lazily initialization
    of the Class's module.

4. An optional module that doesn't any local class but just
    reexports another module is not currently stored in the
    configuration.  Thus the loader can't find it even if it's
    present. jdk.jaxp is an example that reexports sun.jaxp
    as sun.jaxp exports its internal APIs and permits only
    specific module to use (jaxws) while jdk.jaxp only
    reexports the public APIs.

    I simply added the remote contexts list in the configuration as
    the fast configuration work will further change the layout.
    With another change I made in the SimpleLibrary.StoredConfiguration
    class to add indirection for the context name that reduces
    the config file size [3], the remote contexts list should have
    minimal impact to the config size.

Please also note that I added a "Guideline of Using Optional module"
section in [2] which is intended to illustrate the class loading issue
with optional module but not as a recommendation for the coding practice.
This would be another topic to discuss.

Thanks
Mandy

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-May/001298.html
[2] http://openjdk.java.net/projects/jigsaw/doc/topics/optional.html
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-June/001349.html