Re-design and re-implement how the environment variables are propagated across all components

[joanlopez]

Currently, there are different ways the environment (variables) are propagated across all components, making it difficult to reason about and tell what goes where when and in what order, which creates confusion, could easily be a source of bugs, unexpected behaviors and ultimately makes the whole project harder to maintain.

To mention a few:

• There's the cmd/state.GlobalState.Env, which is mainly used to abstract from the real environment, and make the whole cmd package testable. It is injected into output.Params.Env, so it's available/exposed to all the outputs through the constructor contract.
• There's the lib.RuntimeOptions.Env, which is what's injected into the Runner, that's populated with some heuristics based also on cmd/state.GlobalState.Env. It is also injected output.Params, so it's also available/exposed to all the outputs through the constructor contract, as well as to extensions through the modules.VU.InitEnv().TestPreInitState.RuntimeOptions.
• Then, there's also the modules.VU.InitEnv().TestPreInitState.LookupEnv function, and what's exposed through __ENV at runtime.

Which clearly indicates that the current state of environment variables within k6 are a bit of a mess.
So, I'd suggest to elaborate proper docs (perhaps a diagram) about how all those pieces are connected (populated with & used by) and from that, try to re-think, re-design and later re-implement an architecture for environment variables, so they become less messy, from both perspective: maintainability, and usability (UX).