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

This pull request addresses a number of scroller-related issues.
It contains quite a few changes so should be tested thoroughly
against a wide range of existing samples. I worked primarily with
the DataListScrollTestbed sample, but also did sanity checks
against most of the List samples in the Layout library and against
a wide variety of Moonstone samples (various scroll samples,
DataList, DataGridList, etc.). 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.

  The issue didn't occur for other scroll
  strategies (including the non-optimized flavor of Translate)
  because those strategies set the native scrollLeft / scrollTop
  properties of a scrollable region, resulting in automatic
  correction of out-of-bounds values. Because the optimized flavor
  of Translate uses its own CSS-translation-based scrolling method,
  it needs to manually call ScrollMath's stabilize() method at key
  points to ensure that out-of-bounds values are corrected.

* ENYO-485: After a recent change to fix issues with setting and
  restoring scroll position for a hidden scroller (ENYO-371),
  the SmartShare app started taking longer to launch (specifically
  to make its first paint). This regression appears to have been
  indirectly caused by some additional calls to
  ScrollMath.stabilize() introduced by the fix for ENYO-371. These
  calls to stabilize in turn resulted in the firing of onScroll
  events, which themselves triggered expensive layout and paint
  operations in the app. To address this issue, I changed the way
  that ScrollMath.stabilize() works. It now fires an explicit
  onStabilize event instead of firing onScrollStart, onScroll and
  onScrollStop in sequence, and Touch and TranslateScrollStrategy
  have been updated accordingly. This should reduce extraneous
  onScroll events in many circumstances.

* 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)
ENYO-483: Fixing guard code to avoid extraneous scroll events

We need to compare our previous position to the current value from
ScrollMath, not to the value passed in by the caller.

Enyo-DCO-1.1-Signed-Off-By: Gray Norton (gray.norton@lge.com)
BHV-17798: Refactor hold support for better reuse

A recent change to Enyo's hold implementation (enabling the
definition of custom hold events) caused a regression in
Spotlight's own hold implementation. Specifically, the Enyo change
introduced a change in the format used to specify the hold config,
and this change caused problems for Spotlight, which was reading
the config directly and using it to implement equivalent hold
functionality (which was originally copied from Enyo and lightly
modified). Because Spotlight couldn't read the config, the timing
of Spotlight-generated holdpulse events was incorrect.

We made a hot fix on a branch for Enyo 2.5.2-pre.8, but that fix
doesn't cover all use cases and doesn't address the fundamental
issue -- the delicate way in which Enyo's and Spotlight's hold
functionality are coupled. A better fix for the long term is to
refactor Enyo's hold functionality so that it can be shared by
Spotlight.

This pull request covers the Enyo side of that fix. We've
refactored the hold-configuration functionality so that it lives
more completely in enyo.gesture.drag, which provides a very simple
(internal) API that can be used by both enyo.gesture and Spotlight.

At the same time, fixed the hold-resumption behavior, which was
inadvertently broken by the aforementioned recent change. In doing
so, took the opportunity to do some renaming / refactoring for
increased clarity -- specifically, renamed the confusingly similar
stopHold and cancelHold to suspendHold and endHold, and factored
resumption logic out of beginHold.

We really need a new sample to make it easier to exercise our hold
functionality, but will do that in a separate PR in the interest
of getting this one reviewed.

Enyo-DCO-1.1-Signed-Off-By: Gray Norton (gray.norton@lge.com)
Merge pull request #935 from enyojs/more-scroller-fixes-graynorton

ENYO-473, 483, 476, 477: More Scroller / DataList issues

Reviewed-By: Krishna Rangarajan (krishna.rangarajan@lge.com)
Integrated-By: Ryan Duffy (ryan.duffy@lge.com)
update to use faster clone (in the new code -- existing code not updated)
ENYO-485: Add HoldSample, protect against unwanted mutations

Adding a first rough cut at a sample for testing hold behavior.

Cloning the config's events array before modifying it, to avoid
handle the case where someone has passed us a config that they are
keeping a reference to.

Enyo-DCO-1.1-Signed-Off-By: Gray Norton (gray.norton@lge.com)
Merge pull request #939 from enyojs/BHV-17798-graynorton

BHV-17798: Refactor hold support for better reuse

Reviewed-By: Cole Davis (cole.davis@lge.com)
Integrated-By: Aaron Tam (aaron.tam@lge.com)