ENYO-473, 476, 477: More Scroller / DataList issues

This pull request addresses a number of issues:

* ENYO-473: With TranslateScrollStrategy, it was sometimes possible
  to scroll to an invalid position (outside the actual boundaries
  of the scrollable content) if the size of the content happened to
  change during (perhaps as a result of) the scrolling action. This
  situation could easily occur when using DataList, since DataList
  constantly updates the size of the "buffer" it uses to represent
  the list's full size. When this happened, the contents of the
  scroller would disappear from view. The easiest way to see this
  was to  use DataListScrollTestbed, choose the "Translate
  (Optimized)" option, and tap "Scroll to Bottom" (as described in
  ENYO-473). Although harder to reproduce, you could also make this
  happen on a Mac with Magic Trackpad by choosing either of the two
  Translate options and rapidly scrolling up and down by scrolling
  with the trackpad.

* ENYO-476: DataList was not properly refreshing when resized. This
  was because cached page-size metrics were not being invalidated
  after a resize.

* ENYO-477: In TouchScrollStrategy and subkinds, the scroll thumbs
  would often disappear unexpectedly while scrolling was still
  in progress. This is a regression that occurred between 2.4.0 and
  2.5.0, most likely due to changes in when onScrollStop events
  fire. To ensure that this won't happen, we explicitly show the
  thumbs (thus canceling any scheduled "hide" operations) in our
  onScroll handler, not onScrollStart. Because we were already
  adjusting the thumbs' position on every event and Thumb guards
  against redundant DOM changes in its setShowing() method, there
  seems to be little to no performance penalty for this change.

Enyo-DCO-1.1-Signed-Off-By: Gray Norton (gray.norton@lge.com)
Yeah, I agree that asyncMethod is generally to be thought of as a last resort. In this case, there are some messy things going on -- user starts scrolling, which causes list to regenerate and refine its estimate of total scrollable size, which in turn changes the scroll boundaries governing the still-in-progress scrolling operation; meanwhile, TranslateScrollStrategy doesn't set the native scrollTop property and therefore doesn't benefit from an automatic correction of scroll bounds that happens for all of the other strategies (if you set native scrollTop to an out-of-bounds value, it will force itself back to a legal value, but if you happen to be checking scroll bounds a a high frequency while this is going on, you'll see that it happens asynchronously).

Anyway, I tried a bunch of different things and this ended up seeming like the least evil solution. Unfortunately, I didn't document the exact nature of the issue. I'll retrace my steps so and try to characterize more precisely why I ended up here.