These classes now share more code and have feature parity.

Previously we'd always stop org.domokit.sky.shell. If an
AndroidManifest.xml exists, we'll use the activity specified in there
instead.

remove the device factory methods as well as the device cache

add device notifications for the simulator

This splits flx.build() into two methods, flx.build() and
flx.assemble().  builD() now does the following:
1) constructs the manifest map by reading the manifest from the
   file system
2) "compiles" the dart code into the snapshot file
3) Invokes assemble()

This allows external build toolchains to construct their own
manifest map (possibly using a different manifest syntax)
and create their own snapshot file

flutter start no longer depends on a pre-built SkyShell.apk. It builds a
new one, as long as an AndroidManifest.xml exists.

We rebuild the .apk every time either AndroidManifest.xml or
flutter.yaml changes.

fixed sub-process stdout parsing; added todos

Add a --full-restart flag to the start command that controls whether we stop the application process

SkyActivity now allows reloading application Dart code within an existing
activity.  If a SkyActivity instance is already running, then passing
--no-full-restart will restart the Dart code without killing and restarting
the SkyShell application.
(full-restart will remain the default until the engine
that supports this is rolled out)

Also remove the obsolete --poke flag

rename to printTrace(), printStatus(), and printError()

Also fix a bug where the trace command may capture the wrong file
if multiple trace file paths are in the Android log buffer.

Previously we found a lower bound timestamp for the trace path log
by running the date command on the device and parsing the result on
the host.  This could yield an inaccurate result if the device and
host are using different time zones.

The command will now obtain the most recent timestamp in the device's
time format by running logcat.

Also improve the error message a bit if a download fails.

Turns out linux does have an ideviceinstaller package
however it doesn't contain idevice_id or any of the
other tools we use.  Furthermore we don't have
xcrun or the rest of xcode on linux so we can't
manipulate simulators either.

No sense in printing out a warning that ios isn't supported
every time on linux, so I wrapped that block in osx only.

@chinmaygarde @devoncarew

remove device type specific checks

Third-party libraries can now provide their own mojo services. They do
so by adding a config.yaml file to their pub package which contains
- a list of service names and java classes which handles that service's
  registration.
- a list of pre-built .jar files to statically link with the app's shell
  when building the app.

Was failing when starting in the iOS Simulator

@chinmaygarde