nodejs android ios,Support nodejs-mobile on Android and iOS

Thanks for taking a look at this already!

Could you briefly explain how these environment variables are being used?

I'm not the person who discovered the need for those env vars (I mostly just want to condense those comments into code into this PR), but I understand some of them:

npm_config_nodedir: nodejs-mobile builds a fork of node, so we have to override the path where node is typically found, to point to nodejs-mobile

npm_config_node_gyp: we have to override the default node-gyp to point to nodejs-mobile-gyp instead

npm_config_platform: I think nodejs-mobile needs this env var to detect android or ios cross compilation

npm_config_node_engine: not sure why, but I think this is pointing to the specific "version" of node inside nodejs-mobile

cc @jaimecbernardo who authors nodejs-mobile.

Is there a subtle bug that might be impacting Electron as well?

I'm not sure if there would appear bugs in Electron. I ran the tests and all of them passed, including one that flashed an Electron window quickly. I personally care about Neon supporting Electron so I find this important too.

In the linked issue, I see you are adding some RUSTC args. These can be set in build.rs, do you think it's valuable putting a feature in neon to discover this and link it?

If possible, yes, this would be a good feature, but we would need some way of detecting (in build.rs) that nodejs-mobile is being used (maybe through one of these env vars that point to nodejs-mobile-gyp?) in order to point rustc-link-search to the nodejs-mobile-react-native directory. And we'd have to make sure it's nodejs-mobile-react-native and not nodejs-mobile-cordova, and there's the question of how to handle nodejs-mobile-cordova when that is being used in the project. Due to all of these variables, I thought about cutting the complexity and just get things working. I agree with doing it properly though.