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.