Add a lot more buildmessage captures

Many of these (mostly in top level commands in commands-packages.js) are
not super well thought out: they use a new "doOrDie" helper to run some
function in a capture and exit if there are any messages.  We really
need to get a little more thoughtful about the big picture of error
handling (combining "build" errors, network errors, catalog errors,
etc). But this at least allows the addition of more buildmessage
assertions.

At the very least, this ensures that if you edit a package.js in a local
package while "meteor run" is running, that instead of crashing the tool
it properly shows the buildmessage and lets you fix the issue.
test for breaking/fixing package.js
adding versions files to example apps; making sure we don't create example apps with example identifiers by accident
move identifier .gitignore to a higher level

don't copy identifier file, instead of deleting it later. also, make
sure to skip an identifier file in the skel directory if one gets there somehow.
add newline to identifier file
Tell resolver about ECVs of overridden versions

Otherwise trying to use a package with constraint "livedata@1.0.0" when
you are loading livedata 1.0.1 from a local package will fail.
include a backtrace for "got open from inactive"
version bumps for 0.9.0-rc6
add missing capture for make-bootstrap-tarballs
bootstrapped releases should be recommended
implement the --show command
help and tests for show
show-broken flag
20 lines of history rarely shows whole stacktrace
todos version bump

(is this part of the release process? should it be? should we even store
these files?)
when updating an app that runs from checkout, default to default release track
Record package usage on `meteor bundle`

Also eliminated arguments that weren't used anywhere,
and removed an XXX comment that was false (recordPackages
doesn't use buildmessage to report connection failures)
some safety cosmetics around meteor create --package
be more tolerant of unknown keys and some cosmetics
Move DEFAULT_TRACK to catalog module

It's a constant, so no need to have to think "hmm, I wonder if I should
be writing catalog.official.DEFAULT_TRACK or
catalog.complete.DEFAULT_TRACK?"