Ugly hack to deal with shared dependencies.

Java dependency management systems like Maven and Ivy operate under the
assumption that all dependencies are calculated up front, conflicts resolved,
and the whole enchilada linearized and turned into a classpath for a single
URLClassLoader to manage.

Things aren't so neat and tidy in a system like Pacman where modules can come
and go, (eventually) at runtime, and one has to make use of a graph of
classloaders to model the module dependencies. One compromise I made in
reconciling these differences is to have each module compute its full
linearized dependency graph, filter out any depends that are already provided
by the modules on which that module depends, and then stick all the rest into a
single URLClassLoader so that things look moderately normal from there on out.

This breaks down when two unrelated modules (call them A and B) independently
reference some library L. Since A does not depend on B nor B on A, they both
decide to put L in their "private" local classloader. Then some module C comes
along which depends on A and B. If C never sees any of Ls classes, because they
are not part of A or Bs public API, then everything is fine. A has its own copy
of L and B has its own copy of L and no one is the wiser. But if classes from L
*are* part of the public API of A and B, then C causes the JVM to choke on its
breakfast when it tries to use A:L classes with B:L classes.

Fortunately, it's usually easy enough to say "don't use library classes in your
module's public APIs", but that constraint only goes so far. Not using
scala-library classes in modules implemented in Scala would pose something of a
problem. When we eventually support JRuby and Clojure and whatever else, the
runtime libraries of those languages will also need to be thusly whitelisted so
that they can be used by multiple modules.

It may come to pass that I eradicate all traces of Scala from the Scaled public
API and encourage a similar restriction on the public APIs of Scaled modules,
in which case I may someday be able to revert that hackery. But I'm not yet
ready to burn that bridge, so I'll live with this kludge for a while.