* upgrade to linter-0.1.30

* add prefer_is_empty lint
* add directives_ordering lint
* add no_adjacent_strings_in_list lint
* add no_duplicate_case_values lint
* add prefer_collection_literals lint
* add prefer_const_constructors lint
* add prefer_contains lint
* add prefer_initializing_formals lint
* add unnecessary_null_aware_assignments lint
* add unnecessary_null_in_if_null_operators lint

The Wrap widget is a layout that places children in a run in order along its
main axis until it runs out of space. At that point, starts placing children in
a new run that is adjacent in the cross axis.

Fixes #8831

It doesn't need to be in the same file as RenderSliver.

All the clients have migrated to Scrollable2.

- ScrollableList
 - ScrollableLazyList
 - LazyBlock
 - MaterialList

Clients should use ListView instead.

All the clients have migrated to GridView.  Also, remove RenderGrid,
which isn't needed by GridView.

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

This patch adds grid supports to slivers and introduces a ScrollGrid
convenience class for making the common types of scrollable grids.

This patch also deploys ScrollGrid in an example in the Flutter Gallery.

Add SliverList

A SliverList is a linear layout of box children in a viewport that all
have a common, fixed extent along the scroll axis. The layout is similar
to a SliverBlock but more efficient.

This implements a new RenderViewport2 class to replace the existing
RenderViewport class.

We didn't end up using this mechanism.

This widget now lives in Mozart:

https://fuchsia.googlesource.com/mozart/+/master/lib/flutter/child_view.dart

Added a widget that implicitly animates the size of it child.

Also, add a few more debugging flags.

* add import guidance to library-level docs

* add import docs to other packages

* fix review comment

* clarify which libraries aren't meant to be directly imported

A flow layout is optimized for reposition children with transformation
matrices. A flow layout can animate the position of its children very
efficiently.

The old names were getting silly and started stepping on valuable namespace.

The new names are consistent and clear.

Bindings now have a debugRegisterServiceExtensions() method that is
invoked in debug mode (only). (Once we have a profile mode, there'll be
a registerProfileServiceExtensions() method that gets called in that
mode only to register extensions that apply then.)

The BindingBase class provides convenience methods for registering
service extensions that do the equivalent of:

```dart
void extension() { ... }
bool extension([bool enabled]) { ... }
double extension([double extension])  { ... }
Map<String, String> extension([Map<String, String> parameters]) { ... }
```

The BindingBase class also itself registers ext.flutter.reassemble,
which it has call a function on the binding called
reassembleApplication().

The Scheduler binding now exposes the preexisting
ext.flutter.timeDilation.

The Renderer binding now exposes the preexisting ext.flutter.debugPaint.

The Renderer binding hooks reassembleApplication to trigger the
rendering tree to be reprocessed (in particular, to fix up the
optimisation closures).

All the logic from rendering/debug.dart about service extensions is
replaced by the above.

I moved basic_types to foundation.

The FlutterWidgets binding hooks reassembleApplication to trigger the
widget tree to be entirely rebuilt.

Flutter Driver now uses ext.flutter.driver instead of
ext.flutter_driver, and is hooked using the same binding mechanism.
Eventually we'll probably move the logic into the Flutter library so
that you just get it without having to invoke a special method first.

We're getting back to the point where we have a bunch of foundation APIs
and it's getting confusing having them mixed with services/.

Transform applies its transform before painting, but sometimes you want
the widget to layout after its transform has been applied. We can't
handle general tranforms in this way because we can't couple width and
height constriants, but we can handle certain rotations.

Fixes #1214

This patch sketches out the basic widgets for creating Mozart child
views. We're still missing some of the machinery, so we can't quite
create child views yet, but once we supply the ViewHost and teach the
compositor how to actually display the child scenes, we'll have
something that works.

This patch restructures how we size the editing region of the Input widget. Now
RenderEditableLine understands that it's a single-line editing widget and sizes
itself correctly.

ScrollableList2 uses the same pattern as ScrollableGrid, which requires the
client to allocate widgets for every list item but doesn't inflate them unless
they're actually needed for the view. It improves on the original
ScrollableList by not requiring a rebuild of the whole visible portion of the
list when scrolling. In fact, small scrolls can often be handled entirely by
repainting.