node-api: include experimental feature flags in add-on version reported at runtime

This only applies to features that change the behaviour of existing APIs.

We currently have two flags for each experimental behaviour-changing API:

1. A feature flag indicating that it is available within the NAPI_EXPERIMENTAL portion of the API.
2. An opt-out flag indicating that, although the add-on chose to use NAPI_EXPERIMENTAL it does not wish to use this particular feature of the experimental bundle.

In order to avoid going down the experimental code path when running an add-on that chose to opt out of an experimental feature, we need to encode that choice in the version reported to the add-on loader.

If NAPI_EXPERIMENTAL is defined, all experimental features are turned on, unless, for any given feature, its opt-out flag is given.

We can include experimental flags in the version number reported at runtime as follows:

This value ends up on napi_env. At runtime we can check against the bits of this value to decide on the code path. We should probably create a family of macros for making decisions based on the feature flags.

At our Node-API meeting we concluded that we should introduce behaviour-changing features extremely sparingly, because, in order to ensure we do not break our users, even those that have opted into NAPI_EXPERIMENTAL, the testing complexity doubles with each feature we introduce.

Aucun fichier d’implémentation ni test n’est nommé. Commencez par retracer comment la version de Node-API parvient à napi_env et comment les fonctionnalités expérimentales sont représentées à l’exécution ; le travail sera considéré comme terminé lorsque les choix de désactivation seront encodés dans la version signalée et que les vérifications de feature flags proposées seront fournies sans modifier le comportement des versions publiées.