Module system implementation refresh (4/2017)

This issue tracks updating the module system API and implementation in JDK 9. The changes in this update are:

- Move Module and Layer from java.lang.reflect to java.lang (as Module and ModuleLayer). This is #MoveModuleAndLayerClasses on the JSR 376 issues list.

- Derivation of names of automatic modules no longer drop the trailing digits from the module name. This change is needed to align the implementation with the updated #VersionsInModuleNames proposal.

- Dependences on automatic modules now resolved more aggressively. This is to avoid NoClassDefFoundErrors that arise when an automatic module is needed but isn't required by an explicit module. It avoids the workaround that was `--add-modules ALL-MODULE-PATH`.

- The output of `java --list-modules` is tweaked to make it easier to identify automatic modules.

- JVM TI and java.lang.instrument are updated to allow for the possibility that modules are unmodifiable. Not all classes are modifiable so this is just future-proofing the API and makes it consistent with the original intent.

- Change `--add-modules ALL-SYSTEM` (both java and javac) to not skip modules marked as "do not resolve". This removes the inconsistency introduced by the changes in JEP 11.

- Scanning of exploded modules now ignore hidden files when deriving the set of packages in the module. One motive is the annoying .DS_Store files created by the Finder application on OS X.

- ModuleDescriptor.Builder.mainClass(String) needs to be clearer that it adds the package containing the main class to the module.

- Some of the caller sensitive methods updated to support modules don't properly handle the "no caller" case.