Function environment variables from configmaps/secrets

Today, we supply ConfigMaps and Secrets to functions only through files. Supplying them to the function through environment variables instead has been a popular user request. So far, we've avoided this because:

1. Poolmgr starts the container before being associated with a function, so at process start time we don't actually know what env vars a user wants.
2. Newdeploy could do it trivially (just a change to the podspec), but then we'd have inconsistent features across executors, something we've managed to avoid so far.

However, it's possible to implement this feature. Options I can think of:

1. Accept inconsistent features across executors, and enable newdeploy functions to have env vars. So a user can choose either fast cold starts or env vars.
2. Proposal #1536, make poolmgr more like newdeploy and start the function process late enough to get env vars. So all functions can use env vars, but all cold starts become slower.
3. Modify every environment runtime to support env var modification at runtime. We could do this by creating a new env version, adding env vars to the specializeRequest, and interpreting that in the language runtime (i.e. one implementation in each of python, node, go, java, ...). It's relatively more work, but you get no latency regression.