RenderView has to be a singleton for sanity during tests, otherwise they
all end up in the dirty lists and we end up pumping all of them each frame.

AnimatedContainer isn't an AnimatedComponent.

Turns out it gets nothing out of inheriting from AnimatedComponent.

This widget has no client.

Clarify why we don't assert that ancestor != null.

Be more explicit about what's state in dismissable

Move _activeCardDragEndPoint near build() so it's more obvious that it
is part of the build state.

Make a couple of functions use setState() since they modify variables
that are used by build().

Add a more detailed comment to the empty setState() call, since those
are dubious in general and need explaining when they occur, lest people
start using them as magic incantations to Make Things Work.

Follow-up for #1140.

If a StatefulComponent marks itself dirty, gets rebuilt, then its parent
gets rebuilt, its parent will find that its child is from a newer
generation and hasn't changed. Previously, we considered two stateful
nodes to not be syncable even if they were the same; combined with the
way the "old" node looks like it's been put elsewhere (since it's
already been synced), we end up confused as to why the new node is
already mounted.

This fixes the problem by making the canSync logic consider two
identical nodes as syncable (since they are; syncChild() short-circuits
that case), and by changing syncChildren to consider identical nodes as
matches even if they are already synced.

This specifically improves the reporting of exceptions in syncChild(),
and makes the way we've been adding information to toStringName() less
ad-hoc and easier to extend.

Also:

 - don't mark a node as from the new generation if it is dirty, since we
   know it still has to be built.

 - establish the rule that you can't call setState() during initState()
   or build().

 - make syncChild() return early for unchanged children.

 - update the tests, including adding a new one.

Revert "MultiChildRenderObjectWrapper should take an Iterable instead of a List"

This reverts commit 7592213df29066cd357eaa4fffe4a19ed3bae189.

Surface all the constructor arguments of AnimationTiming in all its subclasses.
Remove some pointless casts.
Fix some typos.
Put constructors first in class declarations.
Remove some blank lines where they just confused the structure of the code.

Minor cleanups (spelling mistakes, unneeded casts)

Address more comments from #1153

Various and sundry code cleanup

- Add documentation for AnimationTiming.
- typo: defaules -> defaults.
- added type information to isWatching() signature.
- made Widget.toStringName() include more useful information.
- cleaned up StatefulComponent._sync(): more specific signature, change
  redundant if to else, remove redundant cast.
- change order of TransitionBase arguments for consistency.
- prevent TransitionBase from affecting the performance in its
  constructor when it didn't create it (but see #1103).
- remove TODO() from @mpcomplete... no, there is not currently a better
  way to inherit a constructor, unfortunately.

Almost done adding dartdoc to the rendering layer.

Rename Outter to Outer.

Change _sync() in StatefulComponent to assert the argument type in the
signature rather than in the code.

We now expose idiomatic setters for these properties. Eventually we'll remove
the setter functions.

We didn't mean to flag null ancestors for this debugging check.

Fixes #1140

Add some more docs to the rendering library

If the build stack got long before, it would get cropped.

Disentangle FontSize from Settings

Instead, just store the default font sizes in statics. These statics are
constants for now, but we'll probably make them configurable at some point.

Shrink wrap when constraints are infinite.

Remove init.dart

Rename scroll.dart to drag.dart

ParagraphBuilder should be able to build a paragraph

The gesture is now called "drag". The library name should match.

If it's a StatefulComponent, then it's ok to reuse it so long as it
hasn't been initialised.

If it's a regular Component or a TagNode, then it's always ok to reuse.

If it's a RenderObjectWrapper, then it's ok to reuse so long as it
doesn't have a renderObject.

To put it another way, this changes how we prevent the following
nonsensical situations from arising:

 - Sync two stateful StatefulComponents together
 - Sync two RenderObjectWrappers with RenderObjects together

When either of those cases happen, we just drop the old one on the
ground and use the new one unchanged.