Allow out of tree platforms to work without custom metro configs

[acoates-ms]

Summary:

Currently it is hard to write out of tree platforms that do the right thing, and have a single metro config. Basically as fallout from the removal of haste, now out of tree platforms contain a full implementation of react-native. In order to build an out tree platform you have to redirect any react-native import into an import into to a different package.

react-native-macos and react-native-windows do this today by specifying custom extraNodeModules settings on the metro resolver to redirect react-native to their respective packages. But that requires a different metro config to build macos vs building windows.

We have come up with a new solution that uses a custom resolveRequest function to rewrite the resolutions at bundle time, at which point we know which platform is being built, and can redirect to different packages for different platforms.

This change takes that code and generalizes it into the CLI. So now any out of tree platform can just specify the npm package that metro should use as a redirect for react-native for that platform. -- And otherwise the default metro config should work.

One note, in addition to changing the resolveRequest property, I've changed the assetRegistryPath proeprty. Previously it would be a full path, which would mean that it would not be correctly redirected by the new reactNativePlatformResolver. This path is added as a require statement in the transformer, so it should be fine for most uses as react-native/Libraries/Image/AssetRegistry

Test Plan:

Posting this early for feedback. We recently applied this change to react-native-windows and are still in the process of validating that locally. Then we'll verify that pushing this to the CLI will make everything cleaner. -- So this has not been validated yet.

[thymikee]

Thanks, for this PR. I like the idea of making it easier for platform maintainers to integrate the CLI. Left a few comments on the implementation

[cpojer]

This is pretty smart, I like it. Nice work @acoates-ms!

[acoates-ms]

@thymikee - Getting close to this being ready I think, if you'd like to take another look.
We found an issue related to InitializeCore not getting properly run before the main module. -- But that's fixed in the latest iteration.

[thymikee]

FYI: #1140

[grabbou]

Thanks for the PR. Looks interesting! I like it

Currently it is hard to write out of tree platforms that do the right thing, and have a single metro config. Basically, as fallout from the removal of haste, now out of tree platforms contain a full implementation of react-native. In order to build an out tree platform you have to redirect any react-native import into an import into to a different package.

Does this mean this PR is likely to be reverted when out-of-tree platforms no longer contain a full implementation of React Native? I would guess this is our long-term goal.

[acoates-ms]

@grabbou - The long term goal would be that core is truly platform agnostic, and even android/iOS are in separate packages. But there are no near term plans to get there. -- and its not clear what the metro config would end up looking like in that case. One of the nice things about this change is that the platform has to opt in within its react-native config. So even if things change it should be easy to migrate platforms to opt back out of this behavior.