No N-API equivalent for new well-known-symbol loading feature

[gabrielschulhof]

@bnoordhuis adds support for loading a module by looking for a well-known symbol if the module fails to self-register in 3828fc6. The new code looks for a symbol that matches the NODE_MODULE_VERSION (node_register_module_${NODE_MODULE_VERSION}).

We need to extend this approach to N-API modules as well.

[addaleax]

Does this make sense for N-API? After all, it is supposed to be ABI-stable, so it doesn't need NODE_MODULE_VERSION... or are you suggesting to also look for node_register_module_napi?

[gabrielschulhof]

@addaleax with this change, if you call dlopen() twice on the same file, that will now correctly initialize the addon twice, so this change is a step towards having multi-context native modules, in addition to being a step towards having multi-version native modules.

Fundamentally, if a plain V8 native addon fails to register, it will still have its Init called, if the Init bears the right name. Without additional work, this will not happen if it's a N-API addon.

[gabrielschulhof]

@addaleax I guess the fundamental new feature here is that we now have a tool for finding a symbol given a library handle in a way that is supported across all Node.js platforms. One of my first thoughts is that we may want to

for (size_t version = NAPI_VERSION; version > 0; version--) {
  void *symbol = dlib->GetSymbolAddress((
    std::string("napi") +
    std::to_string(version) +
    "_register_module").c_str());
  if (symbol != nullptr) {
    // Initialize the N-API module
  }
}

Some outstanding questions:

• How do we get the napi[n]_register_module symbols into the modules? Do we modify the definition of NAPI_MODULE()?
• Since the code for looking up symbols is currently in node.cc, we need control to go over into node_api.cc somehow, because the types napi_value and napi_env are not defined in node.cc, and those are the types that need to be passed into the N-API module initializer. So, how do we get N-API to do its thing?

[gabrielschulhof]

Also, #19731 may render this moot, since it allows the re-loading of modules without any special symbol. I just hope we can address all the edge cases of shared library loading in that PR.