Fix event handling

[Szymon20000]

Copied from #1149

Description

Previously, we were handling dispatched events like so:

@Override
 public void onEventDispatch(Event event) {
   if (UiThreadUtil.isOnUiThread()) {
     handleEvent(event);
   } else {
     mEventQueue.offer(event);
     startUpdatingOnAnimationFrame();
    }
  }

Event handling in RN works by utilizing EventDispatcher.dispatchEvent(event) which

1. runs onEventDispatch callback on any registered listener
2. adds event to internal event queue
3. adds frame callback which dispatches and disposes events on JS thread

This approach introduced timing issues - RN's EventDispatcher dispatches events on JS thread and Reanimated handles events on UI thread. There's a possibility that EventDispatcher will dispose event (possibly destroying it's state in onDispose()) before Reanimated would have chance to handle it.
This was found after investigating pretty popular crash in react-native-gesture-handler.

HOW

The pull-request adds another method isAnyHandlerWaitingForEvent to NativeProxy API which lets us check if an event is important (there is workletHandler listening for the event) or not. The rest part of the pr is very similar to Jakub's pr. However, there are some differences. Instead of saving copied event Object, we save: tag, eventName, and payload in the new class CopiedEvent.

[jakub-gonet]

Copied from #1149

Maybe we could also pool CopiedEvent objects same way we have pools of other events. In this case this should be rather efficient as there typically won't be more than 2-3 events in use.

[Szymon20000]

I don't see a need for a CopiedEvent pool.

[jakub-gonet]

Not using the pool will strain GC, event objects will be created and removed frequently if events will be coming from other source than the UI thread.

[Szymon20000]

It doesn't make sense for me because we still have to create and remove events' payloads.

[jakub-gonet]

So maybe @kmagiera will chime in since he suggested this change in the original PR.