Tried to get everything to an rc.0 of the very latest version,
which required some research in some cases about the published
versions. For example, some packages had version histories like:
```
...
1.0.3-winr.2 January 20th, 2015
1.0.3-winr.3 February 24th, 2015 installed
1.0.3 March 17th, 2015 installed
1.0.4-anubhav.0 August 6th, 2015
1.0.4-plugins.0 July 22nd, 2015
1.0.5-galaxy.0 July 17th, 2015
```
In this case, I would bump the version from `1.0.4-plugins.0`
to `1.0.5-rc.0`, skipping `1.0.4`.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
Most people think of package deps in terms of packages, not unibuilds,
but our constraint solver has all these generated "if you're using
foo#os@1.0.0, use foo#web.browser@=1.0.0" constraints. They are just
distracting in errors (which already hide the unibuild part for
clarity) so make sure we don't see them in paths either.
(I could imagine a flag/env var that skips all the removeUnibuild calls
and this special processing, for "gory details" mode.)
Otherwise the DDP call to tinytest/run was blocking client test execution,
in particular Accounts DDP calls won't run concurrently with another DDP call,
even if the first DDP call calls unblock.
