First step towards lazily loading catalog

We still load all the packages at the beginning, but at least we do it
by calling a function that you could imagine could be called later.
calculate versions earlier to be wary of race conditions
slight improvement on the previous hack
Only load packages as they are passed to resolve

(and their transitive dependencies)
Don't load mori module until needed

Slightly speeds up commands that don't resolve constraints
check config file for version before using it
Use catalog.complete instead of catalog.official

Specifically, in cases (like "load the most recent release we know
about") where we don't always want to incur a sync RPC.

Apparently, there is literally no way to get data from catalog.official
without a sync RPC occuring.

This speeds up 'meteor --version' on built releases by a factor of 10
Experiment: remove `unknownItem` flag

Simplifies loading unknown packages/releases.
Force-refresh catalog.complete from catalog.official.refresh.

Of course, if we were to simply set forceRefresh to true from where
catalog.official was calling catalog.complete.refresh, then we would
have looped inifinitely: initializing the catalog with a `versionsFrom`
field pointing to an unknown release would call
`catalog.official.refresh`, which would call `catalog.complete.refresh({
forceRefresh: true })`, which would call `catalog.official.refresh`
because the unknown release is still not found, and so on.

`catalog.official.refresh` doesn't do any of its actual work when called
reentrantly or when called during a `catalog.official.refresh` yield, so
it makes sense for `catalog.complete.refresh` to be part of that work;
in other words, `catalog.complete.refresh` shouldn't be called if
`catalog.official.refresh` is called reentrantly or during a yield, just
as we don't hit the server again under such conditions. And this also
prevents the infinite loop.

For reasons I don't fully understand, putting the
`catalog.complete.refresh` call before the futures are returned didn't
quite work. Turns out the refreshFutures aren't actually used anyway
(Future wasn't imported from this file; I have a sneaking suspicion the
refreshFutures thing hasn't actually been tested) so this is basically
dead code, and I replaced it with just making `catalog.official.refresh`
return immediately when called re-entrantly or during a yield.

Now we're successfully checking with the server before declaring that a
package/release doesn't exist, and not infinite looping if the
package/release really doesn't exist even on the server.
Add catalog.official._refreshFutures back in.

This allows `catalog.official.refresh` to be called during another
refresh that has yielded.

`catalog.official.refresh` still cannot be called re-entrantly, so
`recordOrRefresh` checks if a refresh is in progress before starting a
new one.