autoupdate_client improvements

- use observe instead of observeChanges so that assets is there even if
  not changing

- protect against nonexistence doc.assets
Fix for autoupdate refresh not firing on initial document

If you have an old version of the app loaded, startup won't
pick up the new version.
Fix infinite reload loop running tests

(just a guess at the fix; arbesfeld to fix the fix if necessary)
Fix the fix to the infinite reload loop

…after talking to arbesfeld
Revert "Fix the fix to the infinite reload loop"

This reverts commit 1ad3dd17af7e7bc8973b1dc0169b88f59e5f2c9e.
Revert "Fix infinite reload loop running tests"

This reverts commit 35d816a36347e9f4d21d0c57a0f894cb848203f0.
Fix infinite reload *AND* no-reload bugs in tests

The root of the problem David Greenspan tried to fix was that
__meteor_runtime_config__.autoupdateVersion was incorrectly 'unknown'
when running tests (due to packages/test-in-browser/autoupdate.js being
handled wrong by autoupdate_server.js).  Turns out the right solution is
to ensure the version is known, not to avoid reloading when the version
is unknown.
Do login prompt when talking to package server with expired credential
Add new argument to another loginWithTokenOrOAuth call
Add 'net' tag to "talk to package server" test
Improve treatment of prerelease (dashed) packages

Drop the "at-least" constraint type entirely. It was not user-accessible
and was only used in the form ">=0.0.0" to represent a constraint with
no version constraint at all. This type of constraint is now called
"any-reasonable".

The definition of "any-reasonable" is:

  - Any version that is not a pre-release (has no dash)
  - Or a pre-release version that is explicitly mentioned in a TOP-LEVEL
    constraint passed to the constraint solver

For example, constraints from .meteor/packages, constraints from the
release, and constraints from the command line of "meteor add" end up
being top-level.

Why only top-level-constrained pre-release versions, and not versions we
find explicitly desired by some other desired version while walking the
graph?

The constraint solver assumes that adding a constraint to the resolver
state can't make previously impossible choices now possible.  If
pre-releases mentioned anywhere worked, then applying the constraints
"any reasonable" followed by "1.2.3-rc1" would result in "1.2.3-rc1"
ruled first impossible and then possible again. That's no good, so we
have to fix the meaning based on something at the start.  (We could try
to apply our prerelease-avoidance tactics solely in the cost functions,
but then it becomes a much less strict rule.)

At the very least, this change should allow you to run meteor on a
preview branch like cordova-hcp without getting a conflict between the
prerelease package on the branch/release and the lack of an explicit
constraint in .meteor/packages on that package, because we are
reintepreting the .meteor/packages constraint as meaning "anything
reasonable" and the in-the-release version counts as reasonable.
Fix constraint solver benchmark
Fix hot code push from pre-0.9.0 apps

For 0.9.0, we changed the structure of documents in the
ClientVersions collection. So now we just throw in a single
dummy document in the old format, triggering a reload.

Fixes #2447
Fix 'meteor add x@version' over x@other

Before, we were running the constraint solver with both the new and the
old constraint, which would fail if they were not simultaneously
satisfiable. (We were writing the right thing to disk if it succeeded,
at least.)
Update autoupdate description
Add COMPAT WITH 0.8.3 comment
Arch-specific plugins make a package arch-specific.

Fixes #2449.
prerelease versions shouldn't prompt you do update

Replace catalog.getLatestVersion with catalog.getLatestMainlineVersion,
which skips prerelease versions (those with dashes in the
version). Ensure that this function is only used by high-level commands
like 'meteor list'.  Replace other uses of that function with other
equivalent functions.

Also, don't stack trace on 'meteor add' constraint failure.
Start of History.md for 0.9.0.1
  Fix for SIGUSR2 signals during startup.

  There was a rare race condition where SIGUSR2 can fire before the
  server starts listening, causing some functions to fail. We added
  a future to the synchronous queue to ensure that SIGUSR2 calls
  are queued to run after onListen.