Don't refresh the package cache on the first run

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

Part of #3006.
Cache files.inCheckout
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!
Stop having a ddp-and-mongo isopacket
get rid of catalog.uniload

There is no longer a uniload catalog when running from a release, since
the release contains whole isopackets (programs) not
isopacks (packages).

We only need a uniload-specific catalog when we're actually rebuilding
isopackets (not in order to load them), so we now have it as a local
variable in the two places that build isopackets.

The deleted code in package-loader.js was specific to the prebuilt
uniload package which no longer exists.
Rename unibuild everywhere to isopackets
ServiceConnection directly loads ddp

Caching works fine here.
isopacket docs
Work around legacy constraint solver calls
Ignore .build.* dirs when building isopackets

Neither read from them nor write to them.

Yes, this means that when running from a checkout, rebuilding an
isopacket (eg because you modified ddp or something) is a little
slower. But it's more correct --- having a single cache in the source
tree that's shared between apps (which run in catalog.complete mode) and
isopackets has some serious correctness issues.  And the common case
where no isopackets have to be rebuilt is still fast (./meteor --version
takes about 0.24 seconds).
simplify compiler.getBuildOrderConstraints

We no longer include versions in the interface. The version was only
used to do some error checking, and the error message in question hasn't
shown up in any bugs from users.

Notably, we were NOT using the version to trigger downloads (that
happens in a different place), so it's not super useful to talk about
multiple versions at all.
eliminate compiler.getBuildOrderConstraints

This gets rid of a call to determineBuildTimeDependencies, which calls
the constraint solver. This is step one of getting rid of
determineBuildTimeDependencies.

Note that this changes the build order logic a little.

In 0.8.3 and earlier we always built *all* the packages we *directly*
depended on before building ourselves. And this led to building the
transitive closure, or at least up until we hit pre-built (release)
packages, which couldn't depend on non-release packages anyway.

In 0.9.0 we only built packages we depend on that have plugins, and the
complete transitive closure of plugins within ourself.  This required
the heavierweight constraint solver call, or at least futzing with the
catalog. I think the "don't build direct dependencies without plugins"
isn't a necessary optimization and it's canceled out by requiring you to
run the constraint solver.  The transitive closure issue is real, but
before merging this branch we'll move the _build logic out of
LocalCatalog.