Provide access mouse/touch events in continuously-updating interaction handlers

As a consequence of integrating camera easing into the main render loop (#5743), we've changed (#6005 #6029) the way continuously-updating interaction handlers manage the camera so that, during dragging/scrolling action, we accumulate movement from multiple mouse events between one render frame and the next, and then in each frame, we synchronously update the camera and fire move (and rotate, etc.) events.

Right now, when DragPanHandler, DragRotateHandler, and ScrollZoomHandler fire 'move', etc., they attach the last mouse event as originalEvent, even though multiple mouse events may be responsible for this particular 'move'. Instead, we should either (a) omit originalEvent in these cases, or (b) include an originalEvents array with all of the contributing events.

Start by reading the DragPanHandler, DragRotateHandler, and ScrollZoomHandler implementations and the event-dispatch paths for their continuously-updating actions. Trace how contributing mouse events are accumulated and assigned to originalEvent; done means the emitted move, rotate, and related events no longer misrepresent multiple contributing events, using one of the two behaviors described in the issue.