wip: store re-org / internal api

[ehazlett]

This is a proposal / PR to make machine more maintainable. I want to get feedback on the direction. It does the following:

• make github.com/docker/machine top level package
• move cli to docker-machine
• create an internal api that wraps store and machine operations (refs: WIP: Refactor code out of main package #286)
• moves some non-store related operations (create/remove) to machine (this will enable more datastore providers in the future)
• error types

[ehazlett]

/cc @cjellick @sthulb @nathanleclaire @bfirsh

[nathanleclaire]

Could we just call this directory bin to avoid confusion?

[sthulb]

There's a problem with go get. go get names the binary by whatever directory the main package is in.

By putting it in a docker-machine dir, we can ensure that people will have a binary called docker-machine.

[nathanleclaire]

I'll need a little time to look it over thoroughly, but having just run into some issues with circular imports I'm very in favor of the direction.

[sthulb]

I'm still not fond of an api package :)

[ehazlett]

@nathanleclaire there shouldn't be any import issues -- the tests pass and the binary builds. I will reset and see if I get the same.

@sthulb I know :) I'm up for debate - it seemed to fit. machine to me is the actual machine. We could do something like move it to the toplevel so it's just github.com/docker/machine -> NewMachine or something and perhaps move store into a subpackage - I was inclined to move that to a subpackage anyway since we will probably want pluggable stores in the future.

[nathanleclaire]

@ehazlett Oh, I was commenting that I was running into circular imports with something (unrelated) that I was working on, and I think re-organizing might help with that.

[ehazlett]

@nathanleclaire ah ok cool

[ehazlett]

Closing as #741 implements most of the moving provisioning and create around and this has stagnated with not much discussion. It also looks like we will keep the Hosts name as part of #727