Remove unreachable case in Constraint#isSatisfied
Clean up logic around pre-releases in solver

When it comes to pre-releases, Constraints aren’t “context-free.”  That’s ok for now, but at least hoist the pre-release check out of the innermost loop.  Ideally we’d hoist it higher, but I can see that it’s pretty convenient this way.

Should be identical in behavior to before (differing maybe in some super edge case, but I doubt it).
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!
add comment about build identifier
remove some logs
Don't need to build deps of versioned packages