Automate testing 577

@wallrj and I have experimented with modifying parts of the docs to use wordish.

Also, there is a start of running wordish from trial.

However, what we would like looked at are the issues, as specified in release-process.rst. We think that a reasonable amount of modification would have to be done to wordish to support even our most basic use case (having the engineer install everything, and start up the VMs and only test the outputs of `docker ps` after running `flocker-deploy` multiple times).

We won't catch many regressions with this using wordish's system of putting '...' all over the place, and it would make the documentation much less readable. We would like feedback on the importance of these tests, given how much work it might take, and perhaps feedback on which problems to solve first.

If we are going to go down the wordish route, I don't think that it is a small job and I'm not sure whether it should be a priority at this time.
The reason is probably that `wordish` feeds an extra line of input after each command which echos the exit status of the previous command and its stderr. 
`wordish` uses that extra output both as an identifier that the previous command has completed and to find the status of the last command.
The problem is that for ssh subprocesses, that extra input actually gets fed to and consumed by the `ssh` subprocess. 
If I put a couple of seconds sleep between the supplied command and the marker command, the supplied command has time to exit and the marker is actually run by the parent shell.
Alternatively, if we use `ssh -n`, the ssh command doesn't comsume the input and it is instead interpreted by the parent shell.
There are probably better ways to run the commands and parse their output and exit status.