When container fails to start, 2/3 of containers are not cleaned up. #102

Seems like there's an issue with GenericContainer when a container fails to start correctly. It looks like this is what happens:

• start() runs tryStart()
• tryStart() creates a container, stores the containerId, starts it, and waits for the port to become available.
• the port does not open; tryStart() throws an exception
• the "finally" block in but not before it schedules a shutdown hook to remove the container.
• this happens again two more times; each time the containerId is overwritten
• the first shutdown hook triggers. it cleans up based on the containerId currently stored in the class; that is, the third container that was created.
• the second and third shutdown hooks also trigger, and also attempt to clean up the same ID.
• the first and second containers stick around un-cleaned.

This happens both when the container fails immediately, and when the container keeps running but doesn't ever listen on the port. (In the latter case, the leftover containers are still running!)

import org.junit.Rule;
import org.junit.Test;
import org.testcontainers.containers.GenericContainer;

public class TestBadCleanup {
   @Rule
   public GenericContainer failingContainer =
         new ContainerWithExecSupport("alpine:3.3")
               .withCommand("/bin/sh","-c","false")
               .withExposedPorts(8080);   

   @Test
   public void testBadCleanup() throws Exception {
      // no op
      // this test will pass, but a "docker ps -a" afterward will see two leftover containers.
   }
}