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.