Build Android Node-API modules against a `weak-node-api.so`

[kraenhansen]

When building Node-API module dynamic libraries using our react-native-node-api-modules-cmake we're passing -Wl,--allow-shlib-undefined to satisfy the linker when it's missing the Node-API symbols.

This is not great for a couple of reasons:

• We're essentially allowing any symbol to be undefined, which might open up for unresolved symbols other than those from Node-API, which will lead to hard to debug issues for library developers.
• We're postponing the issue until runtime, since dlopen on Android won't share even global symbols from libhermes.so with the Node-API module dynamic library and it cannot load anyway. It needs to declare libhermes.so (or whatever .so brings the Node-API symbols) as DT_NEEDED (which is added to the binary automatically when linking against an .so).

Instead, we could build a "fake" libnode.so which would provide failing implementations of all the Node-API symbols. We can use this to link against and then update the DT_NEEDED record in the dynamic library when auto-linking into the Android app, at which point we'd know what library brings the Node-API symbols: For now the only option will be Hermes (engine symbols) in combination with our NodeApiHost (runtime symbols).

[kraenhansen]

It is not as simple as I'd like to patch the DT_NEEDED of the prebuilt binaries as I'd like.
We could ask app developer to install patchelf (or download it and build it from source https://github.com/NixOS/patchelf).

Another idea, that we could pursue instead, would be to build our "weak-node-api" dynamic library (which exports all of the Node-API symbols) in two variants:

1. An implementation which has no dependencies and return generic errors when called: This is what developers link against when prebuilding.
2. An implementation which is built "just in time" as part of building the app and links against the correct "libhermes" and our "node-api-host", loads them and performs symbol lookup, deferring execution to the right library at runtime.

For every engine specific symbol, we'd have to generate code like this (using napi_create_object as an example):

typedef napi_status (*napi_create_object_t)(napi_env, napi_value*);

napi_status napi_create_object(napi_env env, napi_value* result)  {
    #ifdef REEXPORT_NAPI
    static napi_create_object_t real_func = NULL;

    if (!real_func) {
        void* handle = dlopen("libhermes.so", RTLD_LAZY | RTLD_GLOBAL);
        if (!handle) {
            fprintf(stderr, "Failed to load libhermes.so: %s\n", dlerror());
            return napi_status::napi_generic_failure;
        }

        real_func = (napi_create_object_t)dlsym(handle, "napi_create_object");
        if (!real_func) {
            fprintf(stderr, "Failed to find symbol: %s\n", dlerror());
            return napi_status::napi_generic_failure;
        }
    }

    return real_func(env, result);  // Call the real function
    #else
    return napi_status::napi_generic_failure;
    #endif
}

[kraenhansen]

This was done as part of #39