refactor: explicit invalidations for native and cpp

[tjzel]

Summary

This pull requests refactors memory management of Worklets and Reanimated.

Basically, since Reanimated can obtain WorkletsModuleProxy and the Worklet Runtimes as shared pointers, it has to release them explicitly during the invalidation stage of Native Modules. Releasing them later on (e.g. via deconstructors) might lead into issues and crashes.

Ideally we'd instead use some different solution here than shared pointers, but it can wait as it's not mandatory at the moment and could be a significant refactor.

Fixes:

• iOS crash on reload
• Android crash on SingleInstanceChecker during third reload

Test plan

• 0.76 iOS/Android Fabric works
• 0.76 iOS/Android Paper works
• 0.75 iOS/Android Fabric works
• 0.75 iOS/Android Paper works
• 0.74 iOS/Android Fabric works
• 0.74 iOS/Android Paper works

[tomekzaw]

The changes look good to me, I left some remarks in the comments. Two more general questions:

1. Why do we need a separate invalidate method? Why can't we just clear the pointers in C++ destructors like we used to do?
2. Once invalidate method is called, shall we add some assertions to prevent us from calling any methods of an invalidated object?
3. Why can't we just use weak pointers to store WorkletsModule in ReanimatedModule? This way there's no strong link between those two.

[piaskowyk]

Could you elaborate more on why performing cleanup in the C++ destructor is considered too late? This isn't entirely clear to me, but it seems to be important.

[tjzel]

@piaskowyk Native Modules are invalidated and destroyed in stages.

This is more or less how React Native gets cleaned up now (e.g. on reload):

1. invalidate() is invoked on all its Native Modules (probably in reverse order of their initialization, but I'm not exactly sure there).
2. React Native instance specific objects, like Shadow Nodes are deleted.
3. Native Modules are released (and deleted).

Our Worklet Runtime can hold instances to various Host Objects, like Shadow Nodes. Therefore, if we destroy our runtime on step 3. it might crash on garbage collection because the C++ side of these host objects is already destroyed. This probably could be mitigated with a different kind of bindings, but it's definitely outside of the scope of this PR.