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).
Clarify that we build isopackets in order
style: space after bang
Merge branch 'isopackets' into devel

Basically, this changes how uniload works. Instead of loading "groups of
packages" (which can be mixed and matched at the uniload.load site,
although they all had to be in ROOT_PACKAGES) via turning them into an
in-memory "program" which is evaluated, we ensure that all possible
loadable programs exist on disk at startup, and then later do the simple
load (no compilation necessary, just reading and eval'ing). These
programs are called isopackets.

For released tools, the isopackets are built when the tool is built. For
checkout tools, the isopackets are built at startup; they use a
buildinfo.json-style file (watchSet and BUILT_BY) to figure out quickly
if they need to be rebuilt.

We are also now careful to not use the PACKAGESOURCE/.build.foo
directory at all during isopacket build. This is a preliminary step for
moving that directory into your app.