Make the preoptimizer work directly on jars.

This is the first and most important step to #392.
It introduces the notion of a Scala.js classpath, which
consists of the core JS lib, the core info files, and the
Scala.js class files, all as virtual files.
It also adds utilities to read such a classpath from
on-disk directories and jar files. For the content of jars,
the files are unzipped as in-memory virtual files.

This brings the time to decide whether preoptimizeJS has
something to do from ~1.5 s to virtual immediacy on Windows.

To follow: make packageJS and run/test tasks support this
virtual classpath as well.
Make packageJS work directly on jars.

This is a second step to #392. Now packageJS also reads its
inputs directly from jars on the classpath, rather than requiring
everything to be extracted on disk.

As was the case for preoptimizeJS, this makes no-op packageJS
being virtually immediate on Windows. Since packageJS is decomposed
in three parts, this is particularly important as the extdeps part
is almost always a no-op, and the two other parts are fast because
they do not operate on much data to begin with.
Make run and test tasks work directly on jars.

This is implemented mostly by having RhinoBasedScalaJSEnvironment
work with a ScalaJSClasspathEntries rather than a sequence of
files to execute. This makes it both more reusable and saner.
Remove unnecessary settings and tasks from sbt plugin.

Now that everything works directly on jars instead of requiring
extracted versions thereof, all the settings and tasks related
to extracting the jars on the classpath are useless.