Allow Input<T> on most/all input parameters on Service and other APIs

[lukehoban]

A concrete example from a user was the Docker build args parameter to new Service(). The following code doesn't work currently, but we should be able to support this:

export let apiEndpoint = deployment.invokeUrl.apply(url => url + deployment.stageName);

let nginxService = new cloudAws.Service("nginx", {
    containers: {
        nginx: {
            build: {
                context: "./nginx",
                args: {
                    "API_URL": apiEndpoint,
                    "FRONTEND_URL": frontendUrl
                }
            },
            memory: 256,
            ports: [{port: 443, external: true, protocol: "https"}]
        }
    },
    replicas: 3
});

[lukehoban]

A other concrete case that a customer ran into - allowing image to be an Input<string> so that it can be composed with new docker.Image(...) more easily.

[lukehoban]

This was fixed for image: with #660. We'll tackle others in M20.

[CyrusNajmabadi]

This is non-trivial currently due to the fact that build-args are used as part of our computation of the repository name we want to generate.

Potential solutions currently are:

1. remove build-args from repo-name genertion. though this might mean potential collisions of docker builds where the args are different.
2. allow build-args to be computed, but require the user to supply a repository-name option themselves if they are computed.
3. Something else?

@lukehoban Any thoughts here on a preferred direction to go? Is there another option you think we could potentially take here?

[CyrusNajmabadi]

Another approach we're taking is simply to remove the cachign layers provided here (i.e. we cache multiple docker builds that have the exact same build comamnd). With the knowledge that this means that consumers that want this sort of non-rebuilding logic would need to pull out that caching themselves.