* Make TabBarView/PageView accessible

* review fedback

* update the intellij doctor check to support the m18 plugin version

* update to support multiple package names

Documentation changes, and, in particular, the ability to lerp from
and to any decoration by lerping via null.

Add hidden options --extra-front-end-options and --extra-gen-snapshot-options to flutter tool (#12219)

This CL introduces 2 hidden options to 'flutter build aot' and 'flutter run' for passing arbitrary arguments to front-end server and to gen_snapshot tool when building and running flutter app in --profile or --release modes.

The ability to pass arbitrary options simplifies various experiments, as it removes the need to change defaults and rebuild flutter engine for every tested configuration.

* Drop invisible SemanticsNodes from tree

A node is invisible if it is outside of the bounds of the screen and if it is not merged into its (partially) visible parent.

Also in this PR: only set `wasAffectedByClip` to true if the nodes has actually been clipped.

* Fix other failing tests

* renaming

* review feedback

* more doc

Previously, we used `Alignment`, which was difficult to understand. Now,
we just use an `Offset` scaled to the child's size, which is much easier
to understand.

These now act the way they used to act if both operands are
FractionalOffsets.  Once you mix in some other AlignmentGeometry
objects, everything gets converted to the AlignmentGeometry coordinate
system.

FlutterLogoDecoration should defer to Decoration for what to do when
it doesn't know how to lerp to/from another kind of decoration.

I'm about to add the BoxBorder and BorderDirectional classes to
this new file, but figured it would make review easier if the move
of the existing class happened first.

This reverts commit f6fe8dc7.

This breaks coverage test
https://travis-ci.org/flutter/flutter/jobs/282472585

* Roll engine

* Pick up updated engine with analyzer fix

* Add new typeArguments override

* Update engine dep

* Up dartdoc version to fix name resolution issues

* Add framework-side support for system text scale factor.

* Rolling engine to e3404b81a53ba3180c7623a6f2190ebb28518f30
  Additional changes rolled in with engine change:
    libtxt: implementation of GetRectsForRange that processes a line at a time - e3404b8
    Provide an entropy source to the Dart engine (#4161) - e1aa867
    libtxt: search for fallback fonts that can match emoji and CJK characters - 8061df1
    Roll skia to e4679fa06a. (#4157) - 267e7a8
    Update buildroot to 53fea9aebbcc39c6522731471a1a45960ee0685e (#4160) - 02ea7ae
    Revert engine Dart roll. (#4158) - 14aab33
    Add support for system text scale factor. (#4124) - b2a7f4b
    Include _http into sky_engine libraries for analyzer (#4154) - b930f10
    libtxt: Remove postprocess_line and improve tracking of X offsets - 86f95f0
    libtxt: remove redundant line_widths (#4152) - 14bf515
    Roll dart to ade37f931e90b0fdb8fe16d6bf6f089545da55b6 (#4151) - 6f1264f

Reorder the code, remove some redundant documentation, improve the
interpolation logic.

This class lays the groundwork for RTL borders.

* ++

* Allow unmerging of SemanticsNodes

* test passing

* ++

* remove prints

* doc comments

* rectify comment

* review comments

Alignment will eventually replace FractionalOffset.

Unlike FractionalOffset, Alignment uses the center as the zero of the
coordinate system, which makes the RTL math work out much cleaner.

Also, make FractionalOffset into a subclass of Alignment so that clients
can continue to use FractionalOffset.

See https://github.com/dart-lang/pub/issues/1714

* Fixing docs for testWidgets.  No functionality change.

...and other minor Border improvements.
And tests.

This changes the merge logic I added yesterday to not support nulls
but instead support BorderSide.none and equivalents. This makes more
sense when dealing with actual Borders.

Temporary workaround to the fact that the Analyzer API
doesn't have a way to turn on asserts in initializers, coupled
with the fact that this file is being parsed by package:intl
using the Analyzer API.

In 85c425ac, a test was added to ensure that widget.onChanged was
fired when the contents of an EditableText changed via system paste
events (e.g. triggered from a TextSelectionOverlay). Due to a long stack
of rebases and (less-than-perfect) manual merge conflict merge
resolution, it was inadvertently added twice.

* Add a check for gradle failing due to missing licenses

* Review feedback Jakob

This patch fixes a collection of issues with widgets involved in text
editing:

  * Fire widget.onChanged on EditableText value change:
    The value of an EditableText is composed of the text value as well
    as other editing-related data such as selection-related information.

    Previously, widget.onChanged() was only called for updates via
    updateEditingValue(). For pastes via a TextSelectionOverlay, updates
    are signalled via _handleSelectionOverlayChanged(), which only ever
    triggered widget.onSelectionChanged(), but not widget.onChanged().

    Both updateEditingValue() and _handleSelectionOverlayChanged()
    perform the value update via _formatAndSetValue(), which is where
    this patch moves the widget.onChanged() call.

  * Correctly update TextFormField value on edits via controller:
    The textual value of a TextFormField exists in two locations:
      1. FormField.value, as with all FormFields and subclasses.
      2. TextEditingController.value associated with the TextField
         underlying the TextFormField.

    Previously, edits to the TextEditingController associated with a
    TextFormField resulted in updates to the rendered TextField widget,
    but did not update TextFormField.value. FormField.value is updated
    via FormField's onChanged function, which is called from the
    EditableText underlying the TextField underlying the TextFormField.
    EditableText only fires onChanged when it receives changes from the
    engine. It does not fire onChanged for changes made to the
    underlying TextController, since the owner of the TextController is
    the one making these changes and thus, already aware of them.
    FormField, however, *does* need to listen to these changes to update
    its value.

  * Adds an initialValue parameter to the TextFormField constructor:
    FormField's constructor already takes an initialValue parameter,
    which specifies the initial value in the field, which is also the
    value to which reset() returns the field.

    Previously, TextFormField took its initial value from the controller
    value (if a controller was passed in) or the empty string (if not).
    This had the undesirable effect that calling reset() always resets
    the value to the current value of the controller... i.e., does
    nothing.

    We now take an initial value explicitly.

* SafeArea

* AnimatedSafeArea

* AppBar test

* Apply feedback

* Update AUTHORS

* Add background and value colors to LinearProgressIndicator

* Add tests for LinearProgressIndicator with colors