feat: support --env option for the runtime build

[guybedford]

This adds a new --env option to the CLI which can be used to specify and define environment variables at build time.

Passing --env A,B,C will make these environment variables get built into the runtime. A warning message will display in the console making it clear that these environment variables are being built into the application:

Writing A environment variable into the runtime from the current process environment
Writing B environment variable into the runtime from the current process environment
Writing C environment variable into the runtime from the current process environment

Passing --env A=alpha,B=bravo,C will set the environment variables for A and B as the strings "alpha" and "bravo", but then still warn that C is being written in from the ambient environment:

Writing C environment variable into the runtime from the current process environment

In the runtime itself, fastly:env will now default to reading these values when set, and only then fall back to environment variables provided by the edge runtime such as FASTLY_HOSTNAME. Initialization environment variables thus override the runtime ones.

Note: There is no option to build in every environment variable from the outer environment, as this would be insecure.

Resolves #1089.

[guybedford]

Tests are currently failing here because the https://http-me.glitch.me/ test server seems to be down.

[harmony7]

I've let the owners of that glitch app know and it is now being looked at.

[harmony7]

The interface makes sense, it's flexible, and its allow-list design makes it safe. However, we still need to be careful about messaging to avoid confusion and problems:

• The values are baked in a build time, so to change the values of the environment variables you actually have to REBUILD and redeploy the app. If you want values that can be used to dynamically configure the app you have to use Config Store or Secret Store
• The values are baked in, so you (probably) shouldn't pass in any secrets this way, because dissecting the wasm it's probably not impossible to find the values in there

[guybedford]

Looks like the service is running again, will aim to land and include in this next release when CI completes. Any further suggestions please let me know.

The values are baked in, so you (probably) shouldn't pass in any secrets this way, because dissecting the wasm it's probably not impossible to find the values in there

Exactly, and we should be clear about this. Note I also posted this related feature request for secret store - https://github.com/fastly/ExecuteD/issues/4573. Suggestions wrt how to better advocate for such a feature are very welcome.