BHV-14914, BHV-13377: Tooltip positioning issues

We have had some tooltip positioning issues, mostly in edge
cases (e.g., tooltips for disabled controls, controls with
invisible tap areas, controls that are dynamically shown or
hidden).

The implementation is a bit tricky; tooltips are usually shown in
response to onSpotlightFocused events, but can also be shwon in
response to onenter events to cover the case where the control
associated with the tooltip is not spottable.

Previously, Tooltip was attempting to determine its activator
whenever a request to show came in, but systematically discarding
that activator in favor of the currently spotted control whenever
possible. This opened the door to issues when switching between
Spotlight modes or when controls were dynaimcally shown / hidden.

We now consistently use the tooltip activator to position tooltips,
no longer assuming that the currently spotted control is our
activator. Doing so required us to rework the way we determine the
activator to make it more reliable, regardless of whether the
tooltip request originated with an onSpotlightFocused event or an
onenter event. TooltipDecorator now uses the sender of the bubbled-
up event to determine which of its children is the activator; we
can't use the originator in the case of onenter events, because
such events ofen emanate from somewhere within the activator's DOM
structure. Then, rather than waterfalling the same event that
bubbled up, we waterfall a synthesized event, with our reliably-
determined activator as the event originator.

This worked fine in all known cases, except that tooltips for
Icon and IconButton were positioned relative to the icon's tap
target, not its visual representation. It turns out that this was
an issue with cached bubble targets, which made the sender of the
onenter event unreliable. We are currently using a hack to get
around this issue: we register a non-existent event handler for
onenter on moon.Icon, which is enough to trick the bubble
caching mechanism.

Enyo-DCO-1.1-Signed-Off-By: Gray Norton (gray.norton@lge.com)

To identify