We've always cached kernel compiles during bundle builds. This adds
caching for kernel compiles during AOT builds by moving caching into the
KernelCompiler.compile() method rather than around each invocation of it.

This also filters buildbot paths included by the kernel compile that are
not present on the local machine at paths /b/build/slave/Linux_Engine/...
The kernel compiler should probably include an option to not emit these
paths in the depfile, since these are used both by Gradle and the
Fingerprinter class.

Previously, Flutter did not support iOS devices with armv7 or armv7s
CPUs. We now support these devices. This eliminates the previous
hardcoded checks that prevented running on simulators of older devices.

We maintain the existing restriction on running on watchOS or tvOS
simulators.

Previously, in non-release (i.e. profile) AOT builds, we were setting
--no-checked and --conditional_directives flags. --no-checked is the
default, and we don't make use of conditional directives in Flutter.

Allows users of Fingerprinter to filter the set of paths collected from
the explicitly-specified paths and those collected from depfiles.

In some cases, depfiles are emitted with files that are not present on
the local disk (e.g. the frontend compiler currently emits buildbot
paths for the dart core libraries and dart:ui). These files will not
materially affect whether we need to re-run a build action for which
they are inputs, since they're not present in the filesystem and
therefore cannot change.

Fixes https://github.com/flutter/flutter/issues/16169

Depending on whether can read the AVD (or it even has all fields populated) we might get extra "empty" columns, so this trims all blank cells from the end.

It feels more nautral to type when doing `--launch x` or `--create x`.

Emaultor keeps running on a seuccessful launch, so this automatically returns after 3 seconds if the process hasn't quit (we have to wait for some period to get stderr in the case of a failure).

I can't come up with a better name; anything with Simulator or Device in it will be confused with the existing IOSSimulator/Device classes (which represent the running devices).

`flutter emulators nexus` will now return only those that'd match (eg. same things that `flutter emulators --start nexus` would match).

And it's not obvious to the use what the ID is.

Added an exists check to ensure we don't try to run if emulator is missing, but that requires the file extension for Windows.