Add function for fetching ECR registry credentials that are compatible with pulumi-docker & pulumi-docker-build

[flostadler]

Using the existing aws.ecr.getCredentials returns credentials that cannot directly be used with pulumi-docker or pulumi-docker-build.
Right now it returns a base64-encoded authorization token containing the username AWS and the password.
In order to make use of them, users first need to base64 decode it, split the string apart and then create the authorization data for the docker providers. This is not intuitive or easy to find. I'm not aware of any scenario where a user would want the raw base64 encoded version because all container tools I know expect user/pass as separate arguments.

The current way of using ECR with the pulumi-docker providers looks like this:

const registryInfo = repo.registryId.apply(async id => {
    const credentials = await aws.ecr.getCredentials({ registryId: id });
    const decodedCredentials = Buffer.from(credentials.authorizationToken, "base64").toString();
    const [username, password] = decodedCredentials.split(":");
    if (!password || !username) {
        throw new Error("Invalid credentials");
    }
    return {
        address: credentials.proxyEndpoint,
        username: username,
        password: password,
    };
});

// or alternatively docker.Image, docker-build.Image
const ecrProvider = new docker.Provider("ecr-provider", {
    registryAuth: [registryInfo],
});

If we had a convenience function that directly returns the data in the right format it could be simplified to this:

const registryInfo = aws.ecr.getDockerCredentialsOutput({ registryId: repo.registryId });
const ecrProvider = new docker.Provider("ecr-provider", {
    registryAuth: [registryInfo],
});

Additionally, the registryId could be made optional because it's the account ID of the ECR repo. If users do not specify a registryId we can default it to the current AWS account.

NOTE: The existing aws.ecr.getCredentials function is implemented as a patch: #4678. When tackling this, we could think about promoting it to a native provider function.

[flostadler]

Turns out there's a function from upstream now, which we can use for that: aws.ecr.getAuthorizationToken. It's a bit unfortunate that a lot of users (me included) would pick aws.ecr.getCredentials over aws.ecr.getAuthorizationToken because they're looking for Credentials...

We should mark getCredentials as deprecated in favor of getAuthorizationToken