Minor clarifications to self-tests code
Refactor selftest.runTests and create listTests

Not extensively tested.  Needs comments describing options to the new functions (e.g. getFilteredTests) and updated usage for `meteor self-test ––list`.

Filtering and running tests now proceeds in stages
- Add “pseudo-tags” like non-matching and unchanged
- Remove tests whose tags are in a list of “tags to skip”
- Run or list the resulting TestList
- Optionally report skipped tests
- Optionally save the testState
Kill iOS simulator every time phonegap shell is redeployed

Fixes the "black screen" problem that users often see.
Add README for publishing mobile apps on `meteor build`

1. Add README files for both the ios/ and android/
   subdirectories of a build directory linking to a
   Wiki page with instructions on how to go through
   the publish process for both app stores.

2. To make the README file more visible in iOS projects,
   and to make the ios directory tree mirror the android
   one, place what used to go in <BUILD DIR>/ios/ into
   <BUILD DIR>/ios/project/. <BUILD DIR>/ios/ now only
   contains the README file.
Install android bundle first, so the not-installed messages appear at the bottom
Improve output of `meteor self-test ––list`
For android splash screens, add a special attr in xml
Add newline to error message
Call utils.sleepMs(1); during package resolution

This is a temporary fix; we should call it less often
Support ––file option to self-test
Show progress bar when downloading a release prior to springboarding
Update 'bundler.bundle' comment
Oracle JDK 8 installs to yet another path
allow user to mark packages as debugOnly and not have them bundle in production mode

(still outstanding: changes to package publication workflow)

A package marked debugOnly in the package source is not to be bundled in production.
Moreover, if a package/app depends on a debugOnly package, that entire tree should
not be bundled. (But we should take it into account when figuring out versions!)

Does the following:

- In the catalog, we have a function that takes in a set of versions and a set of original
constraints and traverses it, recursively, to build a subset of versions that we *should*
bundle, and the corresponding subset of versions that we shouldn't (because they are either
debugOnly themselves or pulled in by debugOnly packages). (We do this in the catalog because
it is an addon onto the results of the constraint solver, tied deeply into our representation
of data)

- In the packageLoader, we keep track packages & versions that we should bundle, and also,
packages that we should exclude. We do this in the package-loader because, essentially, that's the
object that we use to keep the results of the constraint-solver, and we already propagate it to all
functions that care about it. (Possibly we should subsequently rename it later).

- In the compiler, when we figure out buildTimeDependencies, we ask if we need to bundle debug
builds. If not, we filter them out (see above). Also, when we actually build together unibuilds,
we don't touch the ones that the packageloader tells us to exclude (which ensures that they don't make
it into the final product).

- In the project, we keep track of whether this project is building in debug mode. That's because the project
is where we keep the state of our curent project that we are building, and if we are ever in the state of
building multiple things, then that's the code that we would need to touch (see also that we make a similar
assumption when solving constraints).

- Adds the option to keepthe project debug-build-free and calls it in commands when approporiate.
adding the test package used by the debugOnly test
allow publication of debugOnly packages
clean out the forProd option which we no longer use
allow velocity to search for debug-only packages
Take a ––file regex; comments and usage
move the call to setDebug into the same buildmessage that calls getPackageLoader to be safer about ensureDepsUpToDate