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.
Do login prompt when talking to package server with expired credential
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
Add new argument to another loginWithTokenOrOAuth call
Add 'net' tag to "talk to package server" test
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
Revert "Add back two files"

This reverts commit f2cab6651bbdde2d05a70dc420a73644611e14d6.
Revert "Updating ids and links"

This reverts commit 47c5e638b95a266a7466305c9ef937a3df0e6d48.
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 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 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
Update autoupdate description