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: <table> <tr> <td colspan="4">highest 16 bits</td> <td>lowest 16 bits</td> </tr> <tr> <td>feature 1</td> <td>feature 2</td> <td>...</td> <td>feature 16</td> <td>NAPI_VERSION (latest released, i.e. 8, 9, 10, etc.)</td> </tr> <tr> <th colspan="5">or</th> </tr> <tr> <td colspan="5">NAPI_VERSION_EXPERIMENTAL (2147483647) All experimental features are requested</td> </tr> </table> 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.