An API for creating and starting named applications as gear units (fixes #185)

Ready for review.

I've implemented just the bare bones of the `start_container` and `stop_container` APIs which were easily testable using the `FakeGearClient`.

I haven't added any special error handling to these APIs, `GearClient` errors will be passed through to the called. Is that ok for now?

Calling `stop_container` for an non-existent or already stopped container will not result in an error. That's the same behaviour as `GearClient.remove` and it's the same behaviour as the `gear` commandline client (I think).

I've copied just enough of the `_model` module from https://github.com/ClusterHQ/flocker/compare/flocker-cli-deploy-19 to satisfy this ticket. `routes` and `internal_links` attributes can be added in later tickets.

I haven't bothered adding tests for equality of the `Application` and `DockerImage` classes yet because I haven't need to do any comparisons on those objects. But I can imagine that ``Deployment.discover_node_configuration`` will return `Application` instances at which point we can test comparison of those records (hopefully using a testing helper https://github.com/hynek/characteristic/issues/4)

Fixes #185 
Actually, gear does pass through the IMAGE:TAG combination. I was getting confused because of the inconsistent output of `docker ps` https://github.com/dotcloud/docker/issues/6832 and the inconsistent docker command line documentation https://github.com/dotcloud/docker/issues/6833 .

So I've now added a readonly `DockerImage.full_name` attribute which combines the image and tag and I've made tag an optional argument which defaults to "latest".

And the `full_name` is what we now pass to `GearClient.add`.

I've also updated the existing test to assert that the full name is passed to the FakeGearClient.