refactor(containers): container builds use GCS for cache storage

[plumpy]

This makes a few changes:

1. Before the compilation, we pull down a $repo-$branch.tgz file and
   uncompress it (e.g. igor-master.tgz or rosco-release-1.17.x.tgz) to
   the /workspace volume
2. The Dockerfile.compile image is now expected to be a build step. This
   means we can run the container and it will compile files on the
   /workspace volume. Currently, we copy all the files into the
   container, compile them there, and then have to copy them back out.
   This new method is more along the lines with how GCB is supposed to
   work, but it does mean every Dockerfile.compile has to be
   changed to use CMD instead of RUN.
3. After the compile, we tar up .gradle/caches and .gradle/wrapper to
   $repo-$branch.tgz and send it to gs://spinnaker-build-cache. This
   storage bucket is set to auto-delete files that haven't been
   modified in 14 days.

Removing our dependence on the gradle_cache image means that the
various microservices can define their own compile image with different
build tool configurations. I'd really like to have this for the Java 11
migration.

It also means we could move the Debian builds into Cloud Build, since
we aren't depending on them to produce that gradle_cache artifact.

[ezimanyi]

📦 ⚒️ 💰 🎉

[ttomsu]

Thinking a bit here from helping a user compile a docker image - I wonder if there is a way we can compose the Docker images in each repo in such a way that they can docker build a slim/production container by just concatenating each Dockerfile into a multistage build?

Just an idea, haven't explored it at all.