fix: Memory mismanagement with UI scheduled callbacks (#6900)

The pattern we used with scheduling callbacks on the UI thread -
capturing `this` as a reference - is prone to memory issues. Given such
code:

```c++
void WorkletsModuleProxy::scheduleOnUI(
    jsi::Runtime &rt,
    const jsi::Value &worklet) {
  auto shareableWorklet = extractShareableOrThrow<ShareableWorklet>(
      rt, worklet, "[Worklets] Only worklets can be scheduled to run on UI.");
  uiScheduler_->scheduleOnUI(
      [this, shareableWorklet] {
        this->uiWorkletRuntime_->runGuarded(shareableWorklet);
      });
}
```

We are likely to run into accessing invalidated memory during a reload.
This is due to fact that `WorkletsModuleProxy` is managed by some object
held by the instance of React Native. Let's look at the following
scenario.

1. `WorkletsModuleProxy` is created on the JS thread and held by the
`WorkletsModule` Native Module.
2. `WorkletsModuleProxy::scheduleOnUI` is invoked on the JS thread. The
callback is scheduled to be executed on the UI thread.
3. Application's reload gets triggered. A tear down of React Native is
starting on the JS thread.
4. `WorkletsModule` gets destroyed. Therefore, `WorkletsModuleProxy` is
released and also destroyed.
5. The callback is finally executed on the UI thread by the scheduler.
However, `this` has been invalidated. The App crashes.

Keep in mind that this isn't exclusive to thread jumps exclusively.
Calling `scheduleOnUI` on the UI thread could still result in the
callback executing after the memory has been invalidated.

`WorkletsModuleProxy` is only an example here, the problem could
manifest in all the places where we pass lambdas that capture `this` by
reference.

To fix this I refactored the code so everytime we pass `this` to a
scheduled callback, it would be done via a _weak pointer_ which would
lock the object and prevent it from being destroyed while the callback
is being executed on the UI thread.

Perhaps some bits of code don't need this safety measure due to a
heuristic existing that guarantees that respective memory won't be
invalidated before the callback gets executed. However, I found it
extremely challenging and unreliable to come up with these heuristics,
as they could possibly break at any future change of the code.

- ReanimatedCommitHook
- LayoutAnimationProxy
- ReanimatedModuleProxy
- WorkletsModuleProxy
- WorkletRuntime
- NativeProxy

Reloading the app no longer causes a crash on a scheduled UI callback.

Author: tjzel

packages/react-native-reanimated/Common/cpp/reanimated/NativeModules/ReanimatedModuleProxy.h

@@ -54,7 +54,7 @@ class ReanimatedModuleProxy : public ReanimatedModuleProxySpec {
       jsi::Runtime &rt,
       const jsi::Value &workletRuntimeValue,
       const jsi::Value &shareableWorkletValue) override;
-      
+
   void invalidate();
 
   jsi::Value registerEventHandler(

packages/react-native-reanimated/Common/cpp/worklets/Tools/SingleInstanceChecker.h

@@ -52,12 +52,14 @@ SingleInstanceChecker<T>::SingleInstanceChecker() {
   std::string className =
       __cxxabiv1::__cxa_demangle(typeid(T).name(), nullptr, nullptr, &status);
 
+  // React Native can spawn up to two instances of a Native Module at the same
+  // time. This happens during a reload when a new instance of React Native is
+  // created while simultaneously the old one is torn down.
+  instanceCount_++;
   assertWithMessage(
-      instanceCount_ == 0,
-      "[Reanimated] More than one instance of " + className +
+      instanceCount_ <= 2,
+      "[Reanimated] More than two instances of " + className +
           " present. This may indicate a memory leak due to a retain cycle.");
-
-  instanceCount_++;
 }
 
 template <class T>

packages/react-native-reanimated/android/src/main/cpp/reanimated/android/NativeProxy.cpp

@@ -612,6 +612,7 @@ void NativeProxy::invalidateCpp() {
   if (reanimatedModuleProxy_ != nullptr) {
     reanimatedModuleProxy_->invalidate();
   }
+  layoutAnimations_->cthis()->invalidate();
   reanimatedModuleProxy_.reset();
 }