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)