Refactoring the Library API

[Mark Reinhold]

The current Library class is definitely file-centric, and I fully expect
that we'll need to refactor it, possibly dramatically, in order to hook
up javac.

The resolver currently needs just three of the Library methods:

  - List<ModuleId> findModuleIds(String moduleName)

  - ModuleInfo readModuleInfo(ModuleId mid)

  - List<String> listClasses(ModuleId mid, boolean all)

My understanding from our previous discussions is that the first two are
easy to implement in javac.  The last, as you point out, is impossible.

The Library.listClasses method is invoked only in phases 3 and 4 of the
resolution algorithm.  It won't be used by the alternate compile-time
version of phase 3 (still to be written).  It's used in phase 4 only to
compute the set of packages defined in, and exported from, a context.

The compiler can't provide a list of packages up-front either, so it
seems that we'll also need an alternate version of phase 4 which, like
the alternate phase 3, computes a compile-time approximation of the
eventual run-time result.  That approximation will most likely be, for
each context, its set of remote supplier contexts; finding a class will
involve walking the context graph.

The eventual minimal "Library" API can declare just the findModuleIds and
readModuleInfo methods.  It probably makes sense to have that be an
interface so that you can implement whatever JavaFileManager plumbing is
needed in the compiler.  We should think of a better name for it, too;
maybe "ModuleInfoSet" or some such?

These are nontrivial changes, and the elastic on the stretch goal might
still have snapped, but at least we're making progress.

- Mark