feat: make reactHost accessible

[WoLewicki]

Summary:

On bridgeless mode, reactHost is kept in memory even after destroying the DefaultReactNativeHost in brownfield scenario. Since it keeps references to the modules, they are not deallocated, and their initialize methods are not fired again when creating new instance of react-native later. It breaks the behavior of e.g. react-native-screens, which wants to listen for mutations and should get new FabricUIManager: https://github.com/software-mansion/react-native-screens/blob/20b7e83782cd5f79ddd0d61dadc13eeb4db4b258/android/src/main/java/com/swmansion/rnscreens/ScreensModule.kt#L45.

By adding invalidate method, which cleans up the reactHost instance, we can achieve it.

Changelog:

[ANDROID] [FIXED] - add invalidate method for destroying reactHost instance.

Test Plan:

In brownfield scenario, destroy the instance of RN and see that modules are also destroyed.

[cortinico]

/rebase

[cortinico]

Thanks for sending this over @WoLewicki This sounds like a reasonable approach, but I'd like to have @mdvacca 's opinion on this as well

[arushikesarwani94]

IIRC for internal apps use-case we were able to make use of getReactHost().destroy() to address this scenario without needing an explicit invalidate() in DefaultReactHost

cc: @shwanton

[cortinico]

I see that ReactNativeHost already has a clear() method.
Could we instead do the invalidation in the DefaultReactHost.clear() method instead of having to create a brand new invalidate() abstract method?

[WoLewicki]

Ok so clear is a public API for cleaning all of those instances? If so, I think it will be the correct place to put it there then.

[WoLewicki]

I changed it but I am not sure if the INSTANCE is the proper way of getting the instance of kotlin object.

[cortinico]

can you instead override fun clear(), call super.clear() and set the reactHost to null here?

[cortinico]

this is probably not needed