Issue2734

In #2362 we fixed a regression in package scanning caused by the introduction of the modular JRE. It falls short of fully-fledged support for modules. We should do that. While it is fresh in my mind from exporing the current implementation, I'm making brief notes about that further work.

To do:

1. Think about how packaged classes on the file system, and modules on the file system (containing packages), directories on a file system, classic JARs, modular JARs and file systems contained in JARs and ZIPs (and the jrt: file system) can all be placed in a common framework.

2. Re-think the API and class structure of the package manager to use nio Path and URI, and avoid String, File and URL as arguments to denote package locations. Clearly distinguish file system path and class path in API names and documentation. (And let's have the necessary documentation.)

3. Implement a single cache mechanism basically like we have now but properly in binary. (Currently, the cache is technically binary, but we transform the data into comma-separated strings and back on the way in. Leave it as arrays.)

4. The unit of caching is one cache file per module or per "place containing packages", which is often a JAR. Note that a URI (to a place containing packages) could indicate a place on a file system representing the interior of a ZIP/JAR.

5. The time a module was last modified is (probably) that of the module-info.class.