rethink "statically tagged" images

Our current tagging workflow for docker-base goes like this:
- PR a few new features
- tag it
- :shipit:

One use case isn't addressed by this however, and that's to do with Ubuntu security updates. After #11 is merged and released, no code changes are required to upgrade packages which have CVE exploits and patches released. This becomes a problem because our idea of a "static" tag no longer holds when we need to update libssl in a future release.

For example:
- I am running docker-base v0.3.2, tagged shortly after merging #11
- In docker-base v0.3.2, libssl1.0.0 1.0.2g-1ubuntu4.4 is installed
- A new CVE is released, and the patch is in 1.0.2g-1ubuntu4.6

Since no code changes are required to rebuild the image with this new package, we do not need to create a new tag for docker-base. Instead, v0.3.2 would be re-pushed with the new package. This is different than our usual workflow of "once it's released, don't change it".

Perhaps we should re-think the tagging workflow for docker-base and instead continue to use the same tagging scheme as the upstream image ubuntu-slim relies on (the distro release):

```
docker pull quay.io/deis/base:16.04
```

Or perhaps a more dynamic "build number" scheme is required:

```
docker pull quay.io/deis/base:v0.3.2-160923-020215
```

Where the "build number" in this case is the date (yymmdd) followed by time (hhmmss). We can then continue to use v0.3.2 normally as a "rolling tag", but it allows us to release point-in-time builds for the docker-base image when security fixes are released.