constraint solver should know about plugin deps
os was later changed to plugin
constraint edges are by package, not unibuild

Consider the following situation:

  - app uses package P
  - Every version of P contains `api.use('s', 'server')`
  - Every version of S contains `api.use('c', 'client')`
  - There's nothing else around using S or C

When we bundle our app, we will not end up putting any unibuilds from C
into the bundle. That's fine.

The previous version of the constraint solver understood this, and so C
wasn't even part of the constraint solver solution.

HOWEVER, even though C does not contribute any unibuilds to the app
bundle, we still need to compile C in order to compile S. That's because
our current implementation never compiles only part of an isopack, even
if only part of the isopack will be needed for the app.

The structured project initialization done via ProjectContext will thus
decide to not build or load C, which will make it fail to compile S when
it gets around to compiling the client unibuilds in S.

We could make the model more complex by making it possible to compile
only part of S.

Instead, we'll make the Meteor package model simpler.  Constraints, as
far as the constraint solver is concerned, are now at a package level.
So in this case, "C" will actually be part of the project (will end up
in .meteor/versions, etc) even though it will continue to not provide
any part of any of the bundled client or server programs.

This means that nodes in the constraint solver's graph will now just be
package versions, not unibuild versions.  That's already the language
that the constraint solver spoke in as far as its inputs, outputs, and
error messages were concerned!

An example of an app that couldn't be built on the isopack-cache branch
before this commit and can be now is
  https://github.com/glasser/precise-constraints-example
(It can be built with 1.0, but only by compiling a version of `c` that
isn't part of .meteor/versions!)

Note that this also means that .meteor/versions expresses enough to
allow us to implement a simpler constraint check that doesn't need to do
the full tree walk of the constraint solver.  Such a checker would be
implemented as:

  - gather root dependencies and constraints (project constraints,
    release constraints, etc)
  - add the dependencies and constraints from all versions mentioned
    in .meteor/versions
  - see if the choices made in .meteor/versions satisfy these
    dependencies and constraints

This algorithm did NOT work previously, because you couldn't just look
at the constraints coming from `s@0.0.0` and say "they're satifisfied"
because you had to know to "ignore" the constraint on c#web.browser
because s#web.browser is not part of the app, which is not a fact that
actually got recorded in .meteor/versions.

(This commit does not implement this simpler constraint check, though.)
explicitly search for non-weak dep

dep.references ought to never be empty, but if it is we should consider
that to not be a dependency!
Merge branch 'constraint-changes-from-isopack-cache' into devel
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.
PackageCache: Remove on-disk cache and soft reload

On-disk cache will be replaced by a new class.

Soft refresh was an optimization that wasn't actually very optimized in
0.9.0; it used to only have to look at an in-memory WatchSet and check
those files, but in 0.9.0 it also re-read the whole isopack. Will add
this optimization back in if necessary and safe later.
Start on a new lightweight ProjectContext

This one won't be a singleton.  Eventually project.js will be moved into
here.

Add a 'meteor prep' command which exercises new codepaths. It will be
deleted eventually.

So far, it converts .meteor/packages directly into the format that the
constraint solver wants.  (Unlike the existing code which has several
intermediate formats.)
Depend on local packages versions
run constraint solver and make a package map
ProjectContext: download missing packages

Note that unlike the previous implementation, we show a 'downloading'
progress bar iff we actually download any packages.  (In 1.0 we show a
'downloading' message while just deciding if we need to download
anything; on devel right now we never show 'downloading' since that was
confusing.)
First steps towards an IsopackCache.

It comes up with the right order to build and load packages, and loads
prebuilt packages. It does not yet build packages.
I can compile everything!
Cache isopacks to disk, uselessly.

Uselessly because we don't include any build info, so how would you know
when to rebuild?
write out isopack-buildinfo.json

our replacement for buildinfo.json

it's not right yet: unibuilds don't merge in the plugin watchset.
unibuilds need to be rebuilt if their plugins are

Basically, this branch is moving back to the pre-0.9.0 model where you
tell if a dependent package has changed by explicitly putting its
relevant files in your watchset, instead of by including a "build
identifier" which requires a relatively complex calculation.

Notably, let's say you had package P with a plugin, and a package Q that
depends on it.  If a file in P that's neither part of the plugin nor the
package.js changes, you don't have to rebuild Q... but it did change the
0.9.0 "build identifier", which caused an unnecessary rebuild!