Document authentication via environment variables

[baronfel]

In #484 @richlander used these environment variables to enable a novel use case for our tooling: containerizing and pushing an application that was AOT'd inside the SDK container.

In such a container, users can't just volume mount their Docker config.json if they're using a credential helper - that helper may not be usable inside the container. So the only viable config mechanism is the hard-coded auths in config.json, which aren't great or easy to tool around.

We should instead document the existing env vars (SDK_CONTAINER_REGISTRY_UNAME and SDK_CONTAINER_REGISTRY_PWORD) for this use case and others.

[alexeyzimarev]

Maybe it would be clearer after the docs are updated, but how would it work with credentials providers? Like when the username is _json_key?

[baronfel]

It basically doesn't - this environment variable mechanism was specifically created to make it easier for Visual Studio to pass credentials to the container tooling, because VS at the time could authenticate to Azure Container Registry in ways that this tooling couldn't. We've closed that gap now so the original reason for the escape hatch is less valid.

Separately, this escape hatch is flawed in that it applies the same username/password information to both the source registry and the destination registry - tools like Jib that explicitly designed for this use case have separate settings for each end of the pipeline.