Typo fixes

I noticed two small typos: "shorthard" -> "shorthand", remove lone "g"
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.
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.
Remove 'meteor rebuild' and rebuildLocalPackages

This is the first step in removing all references to
PACKAGESOURCE/.build.packagename caches. We will then implement a new
package cache from the ground up.
Stop using the .build.p cache in LocalCatalog
Get rid of a few random spots that refer to .build.