Split test_general into stable and experimental targets

Problem

The upstream test_general test in the Node.js repository compiles a single target with NAPI_EXPERIMENTAL, which links against all experimental Node-API symbols (node_api_set_prototype, node_api_post_finalizer). This means the addon cannot be loaded on runtimes that don't export every experimental symbol.

In the CTS, this forces all test_general JS test files to guard loadAddon behind a check for every experimental feature the addon links against. The result is that even stable API tests (like napi_strict_equals, napi_typeof, napi_instanceof, etc.) are silently skipped on runtimes that don't support all experimental features.

Proposed solution

Split the upstream test_general into separate targets:

1. Stable target — compiles without NAPI_EXPERIMENTAL, includes all stable API functions
2. Experimental target(s) — one per experimental feature, compiled with the appropriate NAPI_EXPERIMENTAL define

This would allow the CTS to test stable APIs independently of experimental feature support.

Current workaround

The CTS ports test_general as a single experimental addon (matching upstream), with all JS tests guarded behind experimentalFeatures.setPrototype && experimentalFeatures.postFinalizer.

References

• Upstream source: https://github.com/nodejs/node/tree/main/test/js-native-api/test_general
• Upstream binding.gyp defines NAPI_EXPERIMENTAL on the single target

从 upstream test/js-native-api/test_general 目录及其 binding.gyp 开始，然后比较 CTS 当前如何移植单个 experimental target。确定 issue 中描述的 stable 和 experimental feature 分组。完成的标准是：stable API tests 可以在不加载所有 experimental symbols 的情况下加载，而 experimental tests 仍然单独受到 guard 保护并且可以 build。