function changeCurrentResponder(responder) {
  currentResponder = responder;
}
RESPONDER EVENT SYSTEM

A single, global "interaction lock" on views. For a view to be the "responder" means
that pointer interactions are exclusive to that view and none other. The "interaction
lock" can be transferred (only) to ancestors of the current "responder" as long as
pointers continue to be active.

Responder being granted:

A view can become the "responder" after the following events:
 * "pointerdown" (implemented using "touchstart", "mousedown")
 * "pointermove" (implemented using "touchmove", "mousemove")
 * "scroll" (while a pointer is down)
 * "selectionchange" (while a pointer is down)

If nothing is already the "responder", the event propagates to (capture) and from
(bubble) the event target until a view returns `true` for
`on*ShouldSetResponder(Capture)`.

If something is already the responder, the event propagates to (capture) and from
(bubble) the lowest common ancestor of the event target and the current "responder".
Then negotiation happens between the current "responder" and a view that wants to
become the "responder": see the timing diagram below.

(NOTE: Scrolled views either automatically become the "responder" or release the
"interaction lock". A native scroll view that isn't built on top of the responder
system must result in the current "responder" being notified that it no longer has
the "interaction lock" - the native system has taken over.

Responder being released:

As soon as there are no more active pointers that *started* inside descendants
of the *current* "responder", an `onResponderRelease` event is dispatched to the
current "responder", and the responder lock is released.

Typical sequence of events:
 * startShouldSetResponder
 * responderGrant/Reject
 * responderStart
 * responderMove
 * responderEnd
 * responderRelease