Support Docker image builds for dev branches without significant per-branch manual work

We anticipate creating short-lived dev branches for new features being developed. Enabling the dev branch builds and publishing the tar.gz/zip results to blob storage is easy, but getting Docker images created/published requires more infra.

I think two approaches generally make sense for different situations, so it would make sense to implement both:

1. When we build a dev branch, have auto-update infra submit the PR into the nightly (#169) branch, with a repo/tag suffix that matches (perhaps roughly) the dev branch name. We would have a new set of Dockerfiles for the dev branch, just like adding a new 1.16/1.17/... folder.

   This keeps the Docker repo relatively simple. We won't branch for each of 1.16/1.17/..., so why branch for a dev branch's builds?

2. Create a new dev branch in the go-docker repo. Otherwise the same as (1).

   This is useful if we need to make big changes in the Dockerfiles or even the go-docker infra itself to support the new dev builds. We would want to work on those changes in a separate branch to avoid destabilizing unrelated nightly images. For example, if we need to modify the environment to e.g. add OpenSSL to our images, this would probably be a good case for a go-docker dev branch.

Start by inspecting the auto-update infrastructure and the existing nightly branch flow referenced in issue #169, then review the Dockerfiles and branch conventions in the go-docker repository. The work is done when dev-branch builds publish Docker images with branch-derived repository or tag suffixes, while supporting an isolated go-docker branch for larger image or infrastructure changes.