198 per module environment

[gabrielschulhof]

This is an alternative to #206. It doesn't tack the napi_env onto any global node object, but rather creates a new one during module registration, and then passes it around, including into the context for all callbacks/accessors/finalizers.

[gabrielschulhof]

@jasongin we need to abort when

1. We have NAPI_PREAMBLE() because it may need to store the last exception, which is stored in the env.
2. We have NAPI_ARG(env, <anything>) because it needs to set the last error if <anything> is null, and the last error is stored in the env.

Really, the only time we really wouldn't need the environment is when a function did not need anything stored inside it, and always returned napi_ok. The closest function we have to that is napi_typeof(), but since it needs to make sure that result is not null, it has a NAPI_ARG() for result, which needs the env.

I've gone through the entire src/node_api.cc file and for all public APIs we have one of the above two conditions. So, I think we need to keep the abort, unless we are prepared to accept that napi_get_last_error_info() will sometimes not return the last error, because when the last error happened, then env was not passed in, so it couldn't be recorded, and thus, if env is around, after all, just not in that one call, then what you get from napi_get_last_error_info() is the second-last error, not the last error.

[gabrielschulhof]

@jasongin if people are more likely to use the C++ wrapper anyway, since it looks a lot like NAN, then we need not worry about the abort so much, because the wrapper will always correctly pass in the env and the users of the wrapper need not worry about it.

[jasongin]

unless we are prepared to accept that napi_get_last_error_info() will sometimes not return the last error, because when the last error happened, then env was not passed in, so it couldn't be recorded, and thus, if env is around, after all, just not in that one call, then what you get from napi_get_last_error_info() is the second-last error, not the last error.

That's actually not a problem: with this change, napi_get_last_error_info() is defined as returning the last error for the env that you give it. So if you give it a null env, then it should return napi_invalid_arg, which would be the same as the last error for any other call that was attempted using a null env. There is no inconsistency.

So I still don't think aborting is the best response to a null env. But this is such a minor thing that hardly anyone will ever encounter, that I don't feel strongly about it.