...now that we have generic methods, their types need to be specified too.

As of Dart SDK 1.22.0-dev.5.0, `Process.exitCode` is no longer
mutable (that SDK version picks up https://github.com/dart-lang/sdk/commit/e5a16b1ca56414af3008afb8833660f95a9d06da).
This change allows the tools code to pass analysis in sdk versions both
before and after that change, to allow for analysis against both the host and
target sdks.

This ensures that accidental usages of dart:io's
file API don't creep in over time.

This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.

This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.

This argument will enable mocking of os-layer process invocations,
where the mock behavior will come from replaying a previously-
recorded set of invocations. At the point of process invocation,
the key metadata for the invocation will be looked up in the
recording's manifest, and iff a matching record exists in the
manifest, the process will be mocked out with data derived from
the corresponding recorded process (e.g. stdout, stderr, exit code).

* Add --record-to option to flutter tools

This option will cause flutter tools to record all process
invocations that occur and serialize their stdout and stderr
to files that get added to a "recording" ZIP file. This is
part of an effort to be able to test flutter tools in a hermetic
environment.

As a side-benefit, this recording should prove an excellent
attachment to any bug report.

With this change, they're run via instance methods on an object
obtained through the context. This will allow us to substitute
that object in tests with replay/record versions to allow us to
mock out the os-layer in tests.