Rename LayeredCatalog refresh -> refreshLocalPackages, drop cached resolver
update initial springboarding for refreshpolicy

Since release.load no longer refreshes, we now need to manually
refresh. This is actually a great thing! It lets us look at modern
releases before legacy releases, which is the proper order anyway!
Expand comments about safety of release.load calls
release.latestDownloaded -> latestKnown, errors

Since 0.9.0 it hasn't had anything to do about anything being
downloaded, just metadata, so the new name is better.

And without auto-retry, there's no need for this to have anything to do
with buildmessage.

Add a bit more support for the very unlikely case that you're running
meteor outside an app and the catalog has no information about any
METEOR@ release.
Commands must declare a refresh strategy

Part of adding a new command is thinking carefully about whether or not
your command needs to access the catalog.  If there are commands without
that careful thought, the tool shouldn't run.
Don't refresh twice before even starting commands
Do cache the resolver after all; resolveConstraints is called a large number of times
We do need to cache the resolver after all; invalidate it correctly
remove unnecessary assertion

add a var
Get a little farther in springboard test
do METEOR_TEST_FAIL_RELEASE_DOWNLOAD not-found
fix springboard test
refresh-related cleanup
more comment cleanup
get rid of most doOrDie calls

catalog.official doesn't buildmessage any more!
Make refreshFailed a global, not a strategy field

This way it works no matter where we call catalog.refreshOrWarn
Set alreadyRefreshed if refresh was succesful
Add ignoreErrors to Refresh.OnceAtStart strategy
During the first background update run, skip the remote catalog refresh

It might obliterate the package resolver cache, and we just did a package sync anyway.

But we don't want to delay it entirely, because we do want the release-version check.
Add comment about why we don't just delay the first update cycle