Copilot-cli: internal/pkg/docker should be more flexible with context and dockerfile paths

[bvtujo]

Our current implementation assumes that the path of the dockerfile is the root of the application and contains sufficient context to successfully build the container. This can lead to problems when:

a) app deploy is invoked from a directory other than root
b) the Dockerfile is not in the root of the repository.

b) can cause problems in two ways: first, if the dockerfile is not in the root or any directory one level down from root, copilot will not automatically discover it; and second, if the directory in which the dockerfile is stored does not contain sufficient metadata and code files for the build system to complete successfully, the call to docker build will fail.

We should rework the docker.Build function to be able to use a context separate from the directory of the dockerfile. One solution might be to use the repository as the context via

docker build --file path/to/dockerfile https://github.com/user/myrepo.git#branch

but this may introduce unnecessary complexity

[bvtujo]

related #997 #980

docker.Build now generates the following call to the Docker daemon:

docker build -t <imageTag> path/to -f path/to/Dockerfile

The context directory is constructed by calling filepath.Dir on path/to/Dockerfile.

This could be extended, however, by adding an optional context field in Manifest.yaml, as follows:

image:
  # Path to the build context directory. 
  context: ./cmd/main
  # Path to your service's Dockerfile.
  build: ./build/docker/fe/Dockerfile
  # Port exposed through your container to route traffic to it.
  port: 8080

By default, context can be set to ./build/docker/fe and functionality will be identical. However, this additional configurability would allow arbitrary project layouts and avoid the problem of build context not containing go.mod or other necessary dependencies for the current service.