Container Build process improvements

The container build process needs to be reconstructed, as it is currently non-functioning, and when it was functioning, it was severely hamstrung by its implementation.

The former process would sync commits to drupalci_testbot upstream to a bitbucket repository. That bitbucket repository is configured to trigger 2 container builds on docker hub for each commit that was pushed, and docker hub itself was *also* monitoring that bitbucket repo for changes, causing 3 builds per commit. Additionally, the containers were configured such that it went Base->phpbase->web, and base->databasebase->mysql etc. Each subordinate container was triggered to rebuild whenever its upstream container was rebuilt. which meant that we would kick of *tons* of builds, that often failed and often took multiple hours to complete.

So, for future containers we will do the following:

1. Start with an *official* container, either as the "FROM" or as a fork with minor modifications (build with debug symbols for core dumps for example)
2. Commits to *this* repository will be watched by drupal.org's jenkins instance and will trigger a docker build on drupal.org's build infra (instead of docker hub)
3. Once build completes, container will be *pushed* to the DrupalCI repositories on dockerhub.

Several things need to happen:

1. #2840565: Determine naming and tagging conventions for the containers.
2. #2840567: Create the dockerhub repositories to store the builds
3. #2840568: Structure the drupalci_environments repo in an organized manner
4. #2840569: Create the jenkins jobs and infrastructure scripts to support building the docker containers
5. #2840570: Convert drupalci / drupal.org configurations to use the new containers