Pre-convert all constraints
Remove or translate all “numbers” besides a.b.c

in test-data.  Importantly, tests still pass!

For example:
- Convert 1.2 to 1.2.0
- Convert 1.2.0.0 to 1.2.0
- Remove 1.2.0.1 completely
- Remove all rcs, betas, alphas, pres, etc.

Remove unused “platform” property.

Next step: Make the test not depend on setting ECVs in order to pass.
Revert accidental committal of client test-data

Client should not get test-data right now; that was just for debugging.
Simulate non-semver `>=` using alternations

The original benchmark/test translated all constraints into either inexact or exact Meteor constraints — that is, Rails’s `~>1.2.3`, `>1.2.3`, and `>=1.2.3` became the inexact `1.2.3`, and `=1.2.3` became `=1.2.3` — but also gave all versions of all packages an ECV of 0.0.0, meaning all versions are compatible with each other.

In order to make this test pass without ECV, we need to emulate pure `>=` (without incompatibility between major versions) in some other way.  So, for each constraint of the form `foo@a.b.c` where `foo` has larger major versions available than `a`, we allow those major versions as well.  For example, if we depend on `foo@1.1.11` and the largest version of `foo` is `3.2.0`, we rewrite `1.1.11` to `1.1.11 || 2.0.0 || 3.0.0` in order to emulate a pure `>=1.1.11` with no concern for major version compatibility.
Merge branch 'devel' into fix-gems-benchmark

Conflicts:
	packages/constraint-solver/constraint-solver-tests.js
Remove unnecessary code in benchmark tests
Merge branch 'fix-gems-benchmark' into devel

The larger, "benchmark" tests of the constraint solver broke when we
got rid of ECVs earlier this week, because they relied on setting the
ECV to get certain package version semantics.  (We didn't notice they
were broken because these slow tests aren't run unless you ask for
them explicitly via an environment variable.)

This branch fixes up the data to behave equivalently but without
relying on ECVs.  It also removes code that post-processes the dataset
by baking the processing into the data itself.  This is appropriate,
because we ought to be able to specify constraint solver tests in a
simple input-data-output-data sort of way.
Comment more about benchmark data