list-sites sorts its output.  fix test.
fix help test
fix 'sync local catalog' test

there was an unnecessarily strong ordering assumption
Remove dormant "no-downgrade constraint" code

Also removes 'update --minor' and 'add --force'.

In the constraint solver, previousSolution (ie, .meteor/versions) was
intended to be used for three purposes:

  (a) The *heuristic* used in the state graph walk to decide what state
      to look at next:
       - VERY STRONGLY prefers not to downgrade *root* dependencies or
         change them to incompatible newer versions
       - Kinda Strongly prefers not to upgrade root dependencies far
       - mildy prefers not to change transitive dependencies (in any
         direction)

  (b) Actual *constraints* are added to the set of constraints we are
      trying to solve, which state that *root* dependencies are not
      to be downgraded.  Additionally, in most invocation contexts,
      constraints are added that say that *root* dependencies are
      not to be upgraded to incompatible versions (1.3.0 -> 2.0.0).
      The only contexts that lack the secondary constraints are
      part of 'update --minor', and 'add --force'.

  (c) A more recent change (past few weeks): When running the constraint
      solver, we actually run the core constraint solving algorithm
      twice. The first time, we add *equality* constraints for all
      of the previous versions.  If that succeeds, great!  We're not
      changing any versions (we may add packages that we didn't have
      before or drop packages that are no longer needed, though).

      Otherwise, we run the constraint solver again without the equality
      constraints.

However, due to a bug introduced in May in 0760ffbc369, (b) actually
*never happened*.  The commit was the one that intended to make the
(b) constraints only be for root dependencies. But the line:

     if (! _.contains(dependencies, uv.name))

is comparing 'uv.name' (something like 'foo#web.browser') to
'dependencies' (a list of things like 'foo'). So in fact, it thinks that
no dependencies are root and doesn't apply the constraints.

That's actually good, because this code is used in many more places than
just 'meteor update', and applying these things as strong constraints
would actually be problematic; eg, it would break 'meteor --release
slightlyolderrelease'!

In addition, the `update --minor` flag was actually not implemented (it
was not in the command declaration).

So for now, we're removing this dead code.  We may reintroduce 'update
--minor' or 'add --force' later.  We trust that the heuristic will do a
decent job of preventing unnecessary downgrades or incompatible upgrades
while still allowing you to run updates to an older version, eg.

(And in the future, we may change 'meteor update' to use the constraint
solver to figure out which release to update to, rather than going for
the latest one that there exists any solution for.)
Revert "Lower version numbers of some third-party packages"

This reverts commit 080f6f60dde001666b46ca389cdeb1292d8bfb4e.

Unfortunately, this broke all packages that were published with
`api.versionsFrom('METEOR-CORE@0.9.0-atm')` that used one of these
packages.
Bundle build before creating time-sensitive URL
rename .meteor/identifier -> .meteor/.id
update tools/tests id files

really, these directories shouldn't have the files, we should copy to a
temp dir...
Support comments in .meteor/.id
Support comments in .meteor/.id file

Make project.rootDir be absolute in 'meteor create'
Merge branch 'clarify-project-ids' into release-0.9.0
Shrink dev bundle by removing 10M phantom zip file

The phantom install process downloads this zip file but doesn't clean it
up.
Reduce size of less module by 60%
vbump for rc12
Update docs app to 0.9.0-rc12
Fix for programs with attributes.json type client
License update
mailmap update
some new lines in error output
Don't pin packages we're trying to upgrade

Now meteor update will actually upgrade the packages it's trying to
upgrade