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

Previously, if a StatefulWidget was marked dirty, then removed from the
build, then reinserted using the exact same widget under a widget under
a LayoutBuilder, it wouldn't rebuild.

This fixes that.

It also introduces an assert that's supposed to catch SizeObserver-like
behaviour. Rather than make this patch even bigger, I papered over two
pre-existing bugs which this assert uncovered (and fixed the other
problems it found):

   https://github.com/flutter/flutter/issues/5751
   https://github.com/flutter/flutter/issues/5749

We should fix those before 1.0 though.

Prep to get us ready to pull in a new dev SDK and bump our analyzer DEP.

* updates `crypto` (required by fresh analyzer)
* fixes newly flagged dead code warnings
* fixes switches that fall through and don't return

Prep to get us ready to pull in a new dev SDK and bump our analyzer DEP.

* updates `crypto` (required by fresh analyzer)
* fixes newly flagged dead code warnings
* fixes switches that fall through and don't return

As of `1.18.0-dev-0`, these cases will get flagged.  In the meantime, the

Previously we were locking down the state even when calling layout in
LazyBlock. Now we lock only when building children. Making this work well
involved moving the catch out of lockState and into the few callers who
actually wanted it.

Fixes #3534

Fixes #3510

LazyBlock is intended as a replacement for MixedViewport. Rather than

maintaining a table of all the observed child sizes (like

MixedViewport), LazyBlock works by dead reckoning the location of the

children based on the existing viewport. This approach makes it easier

to resize children because LazyBlock doesn't cache any additional

information that would need to be invalidated.



This patch contains a first draft of LazyBlock that works in a simple

usage scenario. Subsequent patches will replace

ScrollableMixedWidgetList with LazyBlock and port the existing

ScrollableMixedWidgetList tests over to LazyBlock.



Related to #3075

- Create a FlutterErrorDetails struct-like class that describes an

  exception along with more details that aren't in the exception, like

  where it was caught and what was going on when it was caught.



- Provide a FlutterError static API for handling these objects:



  - FlutterError.onError which is called whenever Flutter catches an

    error.



  - FlutterError.reportError() which handles an error.



  - FlutterError.dumpErrorToConsole() which is the default behavior

    for onError.



- Removes all the existing exception handler callbacks.



- Replaces all the existing places that described exceptions using

  debugPrint with calls to FlutterError.reportError().



- Extend lockState() to also catch exceptions, so that we catch

  exceptions that happen during finalizers.



- Make the test framework catch errors and treat them as failures.



- Provide a mechanism to override this behavior in the test framework.



- Make the tests that used to depend on the exception handler

  callbacks use this new mechanism.



- Make pump() also support the phase argument.



- Improve some tests using these new features.



Fixes #2356, #2988, #2985, #2220.

Adds BuildOwner to manage the dirty list and build processing for
widgets/elements, and adds a widget unit test to make sure separation
is enforced.

Fixes #2723

Fixes #581

And fix the zillion issues that uncovered.

This reverts commit f41b3411, reversing
changes made to e33d8d96.

This was a bad check-in due to my mangling uploading a new version of the branch from a different machine.

This reverts https://github.com/flutter/flutter/pull/2639 and will be replaced by https://github.com/flutter/flutter/pull/2640

And fix the zillion issues that uncovered.

This patch prepares us to pass a BuildContext to RenderObjectWidgets, which
will make it possible to rebuild RenderObjectElements:

 * Delay creation of the render object until mount(). That will let us pass
   `this` to createRenderObject and have the inherited elements be initialized.

 * Cleanup widgets that take builder closures to prepare for their
   RenderObjectElement to be rebuilt more often.

 * Add a test for the interaction between inherited widgets and
   MixedViewport.

Related to #2598

Previously we had totally wrong behavior. Now we have more correct behavior and
testing.

Fixes #1808

The virtual viewport machinery now handles all of these use cases.
Previous clients of ScrollableWidgetList can use ScrollableLazyList
instead.

This patch changes the framework to walk the child list forwards so that build
functions with global side effects do sensible things. Specifically, if you
have a number of autofocusable children, the first one the list will acquire
the focus because it gets built first now.

Fixes #182

We were recomputing which widgets to show only when we were on the other side
of the repaint boundaries. That doesn't work well for pageable lists because we
come to rest exactly on a repaint boundary, which means we don't cull the other
page.

After this patch, we recompute the set of widgets using an edge-trigger when we
hit the boundary. That's better than using a level-trigger so that we don't
continuously recompute the set of widget as we sit at the boundary.

We use the ScrollDirection for more than just scrolling.

Fixes #151

This patch moves PageableList off HomogeneousViewport and onto RenderList and
friends, making it match the new ScrollableList.

When paging a scrollable list, we were trying to read the render object's size
at a time when we're not allowed to read it. Instead, encode the information
into the repaint limit, which is more correct (and faster) anyway.

This patch also changed ScrollableList2 to use an Iterable instead of an
List for its children. This change lets clients map their underlying
data lazily. If the clients actually have a concrete list, we skip the
extra copy and grab the child list directly.

This patch implements the remaining missing features of ScrollableList2.
It should now be nearly a drop-in replacement for ScrollableList. The
next patch will switch callers over to the new machinery.

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.