Add installJSIBindings for turbo modules on android

[Kudo]

Summary:

Add synchronous JSI installation for TurboModules on Android. That would help some 3rd party JSI based modules to get the jsi::Runtime on bridgeless mode.
The iOS implementation will be in a separate PR.

Changelog:

[ANDROID] [ADDED] - Add installJSIBindings for TurboModules

Test Plan:

Added test in RN-Tester TurboModule test case

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	17,959,791	+24,725
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	21,317,968	+24,687
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: 7fffe69
Branch: main

[Kudo]

the runtime could be a dangling pointer in theory. but the lambda would run on js thread and there's the check. so it should not hit to handling pointer crash.

    if (!turboModuleCache || !jsCallInvoker || !nativeMethodCallInvoker ||
        !delegate || !javaPart) {
      return nullptr;
    }

[philIip]

so it feels like one motivation of having this live in native land is that we might have some native dependencies that we want to pass down the the runtime bindings. if that's the case, i feel like this will be called before we could do anything to manipulate the native state of the module, or do you see it differently?

[Kudo]

if that's the case, i feel like this will be called before we could do anything to manipulate the native state of the module

from js side, yes, and that's why we need a synchronous way to install bindings right after initiating the module and before the further js call. i.e.

const module = TurboModuleRegistry.getEnforcing<Spec>('Module');
// globalThis.someJSIBindings should be available here
module.call();

[philIip]

implementation detail, but i think it would be nice if we could have a compile time check here to fail if there's no JNI method here... they have to write C++ anyways to handle the runtime anyways if they're using this API, and maybe we could also obfuscate the pointer cast from them. i am a kotlin noob so not sure if that's possible here

[Kudo]

originally i was thinking to introduce the interface as an abstract class and having fbjni c++ hybrid data. we could scaffold more c++ stuff there. ultimately i thought that abstract class might not be a good idea since some native module might need their dedicated base class.

unfortunately kotlin seems not support interface with public external fun, otherwise it helps to indicate the method should be a jni call.

[Kudo]

close and looking forward to seeing alternative solutions in the future