Don't refresh the package cache on the first run

Part of #3006.
catalog.complete should only have one PackageCache

Part of #3006.
Merge pull request #3032 from meteor/little-package-cache-fixes

Little package cache fixes
Strip esprima/test from js-analyze
Ensure that Npm.strip is applied in all cases

An Isopack object can be created in one of two ways: by parsing a built
isopack from disk, or by compiling a PackageSource (which may or may not
get written to disk).

In the former case, its nodeModulesPath field will be something like
"npm/node_modules", referring to the node_modules directory inside the
built isopack, which has already had Npm.strip applied to it.

In the latter case, its nodeModulesPath field is actually the
pre-stripped node modules directory (eg '.npm/package/node_modules'). So
if we were to use such an Isopack object inside a bundler operation, we
would need to actually apply the strip operation at bundle time.

As far as I can tell it may not actually be possible to trigger this bug
yet, because for some reason we never quite seem to use the built
Isopack in bundler without cycling it through disk. But I've managed to
trigger it on the isopackets branch, and it's certainly a goal to use
our in-memory caches better (and not require unnecessary write/read
cycles).
uniload now works via named "isopackets"

You can only request a named set of packages, not a random assortment.

In future commits, we will pre-build these packages into JsImages and
load them from that. Building packages for uniload will eventually not
involve the .build.foo directories at all.  (All saved packages will be
built in app context, eventually.)
Built tool saves isopackets instead of packages
from-checkout builds isopackets on startup

Nothing actually LOADS from isopackets yet.
uniload from isopackets!