This patch passes down the viewportMainAxisExtent so that RenderSliverPage can
pick it up and size its children appropriately.

This prepares us for a CustomScrollView that takes slivers.

This patch makes Scrollable2.ensureVisible with SingleChildScrollView. A future
patch will extend the implementation to work with slivers. (Although the patch
does include some of the infrastructure for that part of the implementation as
well.)

This patch makes a number of changes to how you can configure a
Scrollable2:

 - The ScrollPhysics is now responsible for creating the ScrollPosition.
   You can override the ScrollPhysics by supplying a `physics` argument
   to `Scrollable`, and the new physics you supply will be applied to
   the default physics inherited from the ScrollBehavior.

 - This patch removes the ScrollPosition/AbsoluteScrollPosition split as
   all clients were operating in pixels anyway and the split made the
   code very difficult to follow.

 - ScrollPosition no longer depends directly on Scrollable2State.
   Instead, it depends on an abstract interface that Scrollable2State
   implements. This change has two benefits:

    a) It removes the circular dependency between ScrollPosition and
       Scrollable2State, which lets us split the code for these classes
       (and several other classes that got wrapped up in that cycle) into
       separate libraries for easier maintenance.

    b) ScrollPosition is no longer bound to Scrollable2, which means you
       could use the behavior machinery to drive other sorts of widgets.
       For example, we could use it to drive Scrollabe1 if we wanted.

...and fix bugs that the tests uncovered.

WRITE TEST FIND BUG

And fix some un-grammatical language below.

* Detects iPad 2 and iPad Retina as unsupported devices.
* Simplifies blacklisting logic.
* Minor improvements to error messages.
* Added unit tests.

This property is wired up to anything and it isn't used. We'll need to find a
better way for clients to control the scroll offset.

Subclassing FlutterAppDelegate is not required for real-world apps, but
it's what 'flutter create' generates, and applies the default behaviours
that most real-world apps will want.

On iOS, generate a FlutterAppDelegate subclass for the application
delegate. This avoids touchesBegan:withEvent boilerplate to handle
status bar taps.

There aren't any interdependencies with the rest of sliver.dart, and that file
is already quite complex.

This widget is a start towards replacing PageableList. There are still a number
of features that we'll need to add before this widget can replace PageableList.

IntelliJ seems to really want these files to have these changes.

This allows us, for example, to wait for the slow mode banner to have
been removed from the screen before triggering a screen shot.

Also, tweak Banner a bit so you can set the color and text style.
Also, cache the text painter between paints.

By default, pass status bar taps to the root view controller in
generated Flutter apps. Developers should customise as necesary if they
later create one or more alternate FlutterViewControllers that they'd
like to forward these to.

If the tool is started immediately after a previous run of the tool, then
the most recent log timestamp may come from the previous run's logs.
The new instance of the tool should not print those logs.

This was happening during runs of the microbenchmark script.

- Out of bound days are disabled and untappable
- Out of bounds months can't be navigated to

With this commit `flutter run --release` and `flutter run --profile` is fully supported on Windows.

* fix issue detecting ios-deploy. fix issue matching IntelliJ Ultimate on Mac

* refactor directory navigation code

Added three widgets that interact with Futures and Streams.

Fixes #7788

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

Add an "s" command to `flutter run` which takes a screenshot.
Make that comment turn off the slow mode banner.

* Add doctor check for Python 'six' module

Required as part of Xcode lldb module. In all likelihood, if we
encounter this situation, the developer is using a custom Python install
(e.g., via MacPorts or Homebrew).

ios-deploy -h/--help returns a non-zero exit code.

Ref: https://developer.apple.com/xcode/