maybe filter out old versions in show too
Move towards non-singleton catalog.complete

We're going to make uniload use a different flavor of "complete" catalog
soon.  So we need to reduce the number of singleton-ish references to
it.

Also, we need one PackageCache per catalog, so stop it from being a
singleton too.
replace uniloadDir hack with BuiltUniloadCatalog

this only affects built meteor for now
don't run git if there's a colon
Move uniload package list to uniload.js

Actually verify that uniloaded packages are in the list. Add missing
'ejson'. Remove (ah well) test that relies on ability to uniload an app
package (which shouldn't work anyway, but it would be nice to test
uniload Assets...)
uniload from checkout uses separate catalog
Use official catalog for springboarding

Read it into memory at initialize time
avoid reentrant complete refreshes
versions update
vbump rc7
add an XXX about a minor inefficiency
Upgrade Node to 0.10.30. Fix npm bug again.
Unbreak springboarding, oops.
Merge branch 'upgrade-node-fix-npm' into devel
vbump for 0.9.0-rc8
some further catalog/uniload cleanup

- The checkout catalog.uniload now does not uniload a resolver, and
  instead just has a trivial implementation of resolveConstraints.
  (The 'built' catalog.uniload already didn't use the resolver.)

- catalog.complete.resolveConstraints now throws an error if there's
  no resolver; this is OK, because creating the resolver now only
  uses the distinct catalog.uniload, so there's no recursion issue.

- don't record version dependencies in packages during uniload (this
  protects against using release.current before it is initialized)

- PackageLoader should never download packages during uniload (this
  protects against using catalog.uniload.isLocalPackage before it is
  initialized)
Lazily load constraint-solver instead of its mori

This should be a performance win (no need to load constraint-solver
unless you actually need to use it!), and it's what I wanted to do
initially instead of lazily loading mori, but it wasn't feasible with
the old super-recursive catalog.

This fixes an issue where running 'curmeteor rebuild' twice (!) died the
second time with a "Can't load npm module 'mori'" error. This is because
uniload (when run from a checkout) sets up Npm.require to read directly
from PACKAGE/.build.PACKAGE/npm/node_modules, which might get deleted
later in the process!  There are some complex and maybe slow ways to
resolve this general issue (copy the node_modules somewhere else?) but
for now, the easiest way to avoid the issue is just to load Npm modules
immediately inside packages which need to be uniloaded.
Comment about nodeModulesDirectories structure
app versions bump, grr
release metadata is in official only

The point of the other catalogs is to allow local packages to override
server packages. This has nothing to do with releases. So rather than
keep release metadata in memory multiple times and force developers to
wonder "what's the different between catalog.complete.getReleaseTrack
and catalog.official.getReleaseTrack?", now it really just only exists
on catalog.official.