Refactor Plugins to Provider module

### What
Refactored the way we communicate with available vms on a private network.  We now guess where lighthouse is running and interface with the provider in a particular way.

### Endpoints
* ```/provider/vms``` A GET endpoint that returns a json array of private vms available. [example here](http://146.148.78.229/provider/vms)
* ```/provider/which``` A GET endpoint that indicates which provider the backend is configured to. [example here](http://146.148.78.229/provider/which)

### Provider "Flavors"
* __gce:__ This is applicable if we can detect google metadata endpoints.  We can then assume that we have access to the gce api and make calls to it to discover vms.
* __local:__ This is only applicable if the ```DOCKER_HOST``` environment variable exists.  We can then assume that we have access to the local Docker daemon through the ```DOCKER_HOST``` address.
* __unknown:__ This is only applicable if no other provider flavor can be determined.  The intentions of the flavor is to only return empty responses.

### Models
#### VM
* __Name:__ The human readable name of the vm instance
* __Address:__ The private address of the vm.
* __CanAccessDocker:__ Indicates if lighthouse can make api calls to the hosted Docker daemon.

### Notes
* Instead of using Google Two-Factor Authentication, we now require that vm running lighthouse has elevated privileges to view and modify gce instances.  It's a setting that's set when creating a gce instance. This should make it much easier for lighthouse to interact with the compute engine api.
![screen shot 2014-10-21 at 8 52 34 am](https://cloud.githubusercontent.com/assets/2288912/4876628/b6d2f00c-62cc-11e4-9d7d-ae76b00dd5eb.png)
That seems fair, when I get time I'll add a ```port``` field to the VM struct. For now though I'll probably just default them to ```2375```.  Same for ```version``` which will probably be defaulted to ```v1```.