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).