Fixes #1034, at least for start and listen.

We've been bulding these binaries using Travis for a while. We can start using
them now.

1) Moved basic utility code into base/ directory to make it clear which code
   doesn't depend on Flutter-specific knowldge.
2) Move the CommandRunner subclasses into a runner/ directory because these
   aren't commands themselves.

This updates the Flutter tools to match the proposed new packaging of artifacts
in the engine release script.
* The GCS URL for artifacts is now gs://mojo/flutter/$revision/$platform
* Categories have been removed from the Artifact class
* All artifacts for a given platform now live in a zip file.  If an artifact
  is not present in the local cache, then the zip will be downloaded and
  extracted.

Note that darwin-x64 artifacts go through a different process that (for now)
continues to use the old format.

This makes run_mojo more similar to flutter start.

The new flutter.mojo is ready for use.

Other changes in this patch:
- Make the 'flutter' tool say "Updating flutter tool..." when it calls
  pub get, to avoid confusion about what the pub get output is about.
- Make the bash flutter tool call pub get when the revision has
  changed. (This was already happening on Windows.)
- Fix a raft of bugs found by the analyzer.
- Fix some style nits in various bits of code that happened to be near
  things the analyzer noticed.
- Remove the logic in "flutter test" that would run "pub get", since
  upon further reflexion it was determined it didn't work anyway.
  We'll probably have to add better diagnostics here and say to run the
  updater script.
- Remove the native velocity tracker script, since it was testing code
  that has since been removed.

Notes on ignored warnings:
- We ignore warnings in any packages that are not in the Flutter repo or
  in the author's current directory.
- We ignore various irrelevant Strong Mode warnings. We still enable
  strong mode because even though it's not really relevant to our needs,
  it does (more or less accidentally) catch a few things that are
  helpful to us.
- We allow CONSTANTS_LIKE_THIS, since we get some of those from other
  platforms that we are copying for sanity and consistency.
- We allow one-member abstract classes since we have a number of them
  where it's perfectly reasonable.
- We unfortunately still ignore warnings in mojom.dart autogenerated
  files. We should really fix those but that's a separate patch.
- We verify the actual source file when we see the 'Name non-constant
  identifiers using lowerCamelCase.' lint, to allow one-letter variables
  that use capital letters (e.g. for physics expressions) and to allow
  multiple-underscore variable names.
- We ignore all errors on lines that contain the following magic
  incantation and a "#" character:
    // analyzer doesn't like constructor tear-offs
- For all remaining errors, if the line contains a comment of the form
    // analyzer says "..."
  ...then we ignore any errors that have that "..." string in them.

That way we can control if we want to use devtools to run on Linux and
also cleanly separate out the two uses.

R=@jamesr

This flag builds a local FLX file and pushes that to the device instead of
using an HTTP server.

Made changes as discussed.
R=@jamesr

This patch makes `flutter start` work without a clone of the engine git
repository. Making this work pulled a relatively large refactor of how the
commands interact with application packages and devices. Now commands that want
to interact with application packages or devices inherit from a common base
class that holds stores of those objects as members.

In production, the commands download and connect to devices based on the build
configuration stored on the FlutterCommandRunner. In testing, these fields are
used to mock out the real application package and devices.

I'm trying to get a feel for the code by writing some simple cleanup patches.

In 0.0.15, additional cmdline arguments were not dropped, but now in 0.0.16, the arguments are no longer forwarded.
This patchset would restore this forwarding functionality.

For example, the following command is intended to pass `enable-multiprocess` to the mojo_shell.
`enable-multiprocess` in 0.0.16 does not get passed along, but this patchset would allow it to once again.

pub run sky_tools -v --very-verbose run_mojo \
	--mojo-path $MOJO_DIR/src \
	--app app.flx --android \
	-- \
	--enable-multiprocess

Also add unchecked runSync wrapper and use it in places where command failures don’t matter.

Also refactors the command line assembling to make a bit more sense.

Fixes #53

This makes the 'package-root' option universal for sky_tools and configures the
ArtifactStore with it statically at startup. The actual sky_engine revision
is computed on demand.

The flags control which build of mojo to run (Debug or Release).
Default is Release.

Refactor all the commands to be Commands from the Args package.  Also use CommandRunner for the top-level command.

sky_viewer.mojo no longer needs a window manager embedding as of
sky_engine 0.0.27, so this updates the sky_tools run_mojo command so it works
again. This really should be expressed in the pubspec dependencies to avoid
broken combinations but that needs to happen on the sky side.

This teaches commands that need binary artifacts to explicitly instantiate an
instance of the ArtifactStore with the appropriate packageRoot string. The
ArtifactStore can then remember the package root and compute the engine
revision when created and remember those for subsequence calls.

This teaches sky_tools mojo_run --android to invoke mojo's devtool's mojo_run
script with the right flags for invoking sky_viewer on android. This tells the
devtools script to load sky_viewer.mojo from https://storage.googleapis.com/...
and to load app.flx (or whatever the developer specifies as --app) from the
filesystem using the devtools http server.

This initial version assumes the developer has mojo_shell and all other services
sitting on disk somewhere and that they're on linux and only want to run on
linux. This can be generalized down the line to support more use cases. This
downloads the sky_viewer.mojo corresponding to the packages/sky_engine/REVISION
in the developer's directory, so they can specify whatever revision they want.
sky_tools run_mojo downloads sky_viewer.mojo into its cache directory if it is
not present and constructs a command line to pass to mojo_shell that maps the
shebang stamped into the flx to the downloaded sky_viewer.mojo.

Since sky_viewer.mojo lives in the cloud and mojo_shell can load from the cloud
this could also map to an https URL. This should likely be an option.