Build addon paths in TypeScript and expose dlopen(module, filename) #498

Move platform path construction out of native code and expose a raw loading function that matches Node's process.dlopen. This is the shape core would eventually own (#447).

Decisions

• Signature: dlopen(module, filename), with the same semantics as Node's process.dlopen and nothing added, so a difference from Node is a bug.
• Name: exported as dlopen from react-native-node-api, and proposed as react-native/node-api for core. A bare dlopen is too ambiguous as a top-level react-native export. See Rename `requireNodeAddon` to `dlopen`? #263.
• filename: what gets passed to the system's dlopen: lib<name>.so on Android, @rpath/<name>.framework/<name> on Apple. Core knows nothing about our layouts or naming.
• No cache: a second call runs the addon's init again, as in Node.
• No flags for now: adding an optional argument later breaks nobody.

Steps

• Move the path construction in CxxNodeApiHostModule::loadNodeAddon into TypeScript.
• Expose dlopen(module, filename). Exports reach JS through a generated global today (RN$NodeAddon_%p), so this needs a way to set module.exports.
• Rebuild requireNodeAddon on top of it, moving the exports cache out of nodeAddons_ into TypeScript. Keep the behaviour of not caching a failed load. Its library name argument and the Babel output don't change here.
• Confirm the cache stays per runtime.

Known differences

• hermes_napi_load_module creates its own exports object, whereas Node hands module.exports to the addon's init. Until Hermes changes, the result is assigned to module.exports.
• Each load creates a new napi_env, which lives until the runtime is torn down.
• Removing the cache exposes a Hermes bug: NAPI: hermes_napi_load_module can run another addon's init through lastRegisteredModule meta/hermes#2280 can run the wrong init for addons using napi_module_register. Today nodeAddons_ hides the reload case.

The { packageName, path } resolver is #222, layered on top of this.