fix: crash on OTA reload

[tjzel]

Summary

Fixes #7182
Requires #7197

Currently on iOS React Native can go into a non-fatal race condition on a double reload. Double reload can happen during an OTA update, when an app is reloaded immediately after evaluating the bundle.

The flow goes more or less like this. I haven't explored it to the deepest details.

1. On the first reload a new JavaScript runtime is created.
2. The new runtime evaluates the bundle, starts to populate RCTModuleRegistry.
3. On the second reload a new JavaScript runtime is created. The old runtime remains and keeps executing. Both runtimes execute on the same thread, on the same queue.
4. WorkletsModule.installTurboModule() is called from the first runtime. WorkletsModule is fetched from the RCTModuleRegistry.
5. The second runtime overwrites (clears) the RCTModuleRegistry and starts to populate it. I don't know why both runtimes target the same instance of RCTModuleRegistry.
6. WorkletsModule.installTurboModule() finishes successfully on the first runtime.
7. ReanimatedModule.installTurboModule() is invoked in quick succession on the first runtime.
8. ReanimatedModule tries to fetch WorkletsModule from RCTModuleRegistry. However, RCTModuleRegistry was wiped and it doesn't have the fully installed instance of WorkletsModule anymore. Therefore a new instance of WorkletsModule is created and inserted into the RCTModuleRegistry.
9. In JavaScript we guarantee that ReanimatedModule.installTurboModule() is invoked only after WorkletsModule.installTurboModule(). We follow that heuristic in ObjC and therefore try operating on a non-installed instance of WorkletsModule resulting in a NullPtrException.

We can effectively detect that flow and ignore it, since that race condition is fatal only for the first runtime which is torn down soon after anyway.

See the provided screenshots which illustrate the problems.

Setting moduleRegistry for WorkletsModule during a healthy execution of WorkletsModule.installTurboModule()	Setting moduleRegistry for WorkletsModule during race-condition execution. Note that the list of the modules is much shorter and that WorkletsModule isn't there.

Test plan

To reproduce this issue, reload twice on iOS in fabric-example. For best effect try to reload after ~0.5s after the first time, but it's easily reproducible if the App isn't slowed heavily by debugger instructions.

With these changes Reanimated doesn't crash, but the race condition continues to manifest.

[tjzel]

cc @lukmccall

[RSNara]

I don't know why both runtimes target the same instance of RCTModuleRegistry.

So, I initially made this change. The rationale: RCTHost can leak a reference to the module registry to the application. We didn't want that reference to break across reloads. That's why we had the host own the module registry.

But, yeah. This is a little bit problematic. Now, it means that two different interleaving react instances can share the same module registry, leading to undefined behaviour. In this case, the first react instance is accidentally using modules from the second. The module registry should probably be owned by the react instance.

[tjzel]

@RSNara Yeah, I encountered this problem before but didn't pay it much attention since it happened only on multiple reloads. It came back at me when it turned out that OTA updates are done via a double reload 😿 It's an easy fix on our side since we only obtain a TurboModule once, but libraries which pull them multiple times in runtime could be in more trouble.