Fix: a failed Start() breaks --volumes-from on subsequent Start()'s

When starting a container with --volumes-from, if one volume is unavailable (e.g. the container does not exist yet), then subsequent starts (i.e. even once the volume has been created) will ignore the container that failed during the first Start().

Example:

  + Create and start `data_1`
  + Create and start `client`, with `--volumes-from data_1 --volumes-from data_2`. This fails because `data_2` does not exist.
  + Create and start `data_2`
  + Start `data_1` again. This passes, but `data_2`'s volumes aren't mounted (note that although I haven't tested it, but that I actually think you get the same behavior even if you don't create `data_2`).

This seems to be due to `container.Volumes` being left in an inconsistent state if one of the containers in `hostConfig.VolumesFrom` is unavailable.

I included a failing test that demonstrates this issue (in a separate commit — running it without the fix will make the issue apparent).

NOTE: I'm not really a Go person. I'm happy to make edits to the provided PR, but a bit of guidance will go a long way ;)
This should be called TestStartVolumesFromFailsCleanly