avoid using env vars in /run in runtimes

This is to discuss replacing use of environment variables in runtimes with some other object ( e.g. "context") that is explicitly provided to actions, to avoid issues when runtimes support concurrent activation processing, and simplify the per-activation metadata provided to action developers.

_This requires no change in OW core, but does require changes in all runtimes (assuming consistency is important) so rather than create many issues across all repos, I'm creating this one issue to start with..._

Some discussion here:
https://lists.apache.org/thread.html/4b75db671e5f52c11bad6e3073c4cb4170d2ef0fdfb0cd73bed259b0@%3Cdev.openwhisk.apache.org%3E

In general, during concurrent activation processing, referring to (e.g. in nodejs case) process.env will be inaccurate, if that is set during each activation as is done now:
https://github.com/csantanapr/incubator-openwhisk-runtime-nodejs/blob/master/core/nodejsActionBase/src/service.js#L163

However, disabling process.env usage will be a breaking change.

A general plan for deprecating env var usage and allowing migration to new main signatures should be provided.

For nodejs, we can:
- enhance process.env with a dynamic (getter) property a la `Object.defineProperty(process.env, key)` where value is dynamically calculated based on the current activation
- also capture keys into a new context arg
- change the main function invocation to send the context arg (as well as params)
- generate a warning log for usages of process.env[key] (to signal to devs that they will need to migrate to the new signature)

For java (and others), I think similar will work, although I'm not sure how simple it would be to intercept the env getter to inject a warning log. Each runtime will need to have some way to disambiguate the env var access in order to support concurrency without changing to use the new main function signature (`main(params, context)`), but additionally, each runtime should also change to support structured logging (activation id included with each log event), if it wants to support concurrency, so it should be considered to do BOTH of these at the same time, in each runtime.