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
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 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.
