gpm bootstrap command

### Pros

`gpm bootstrap` is intended to help users adopt gpm by creating a Godeps dependency file  based on the Go code of a project, management of the Godeps file after this initial creation is up to the user but gpm ensures that they have a decent starting point, this makes it easier for beginners. 

Sample usage:

```bash
Hyrule ~/code/gpm/test   (git: gpm_bootstrap)
▸ cat go_code.go
package main

import (
	"fmt"
	"github.com/pote/gpm-testing-package"
)

func main() {
	fmt.Println(gpm_testing_package.Version())
}

Hyrule ~/code/gpm/test   (git: gpm_bootstrap)
▸ gpm bootstrap
>> Installing dependencies.
>> Adding package github.com/pote/gpm-testing-package version v6.2  to Godeps.
>> All Done.

Hyrule ~/code/gpm/test   (git: gpm_bootstrap)
▸ cat Godeps
github.com/pote/gpm-testing-package v6.2
```

### Cons

This is a rather complex feature, and and imperfect one too. As a discussion starting point we can see that this PR takes `bin/gpm` from 78 LOC to 179, which speaks volumes: is the complexity inherent to this feature worth the readability/maintenance overhead for the project? I'm not sure, I would hope we can discuss that in this PR.

The second downside is that this feature is imperfect: it uses `go list` to get a list of packages imported in your Go project, but this listing is not straight forward to use: it includes subpackages too, you can see this in the following sample usage:

```bash
Hyrule ~/code/minimalweather  (git: master)
▸ go list -f '{{join .Deps "\n"}}' | xargs go list -f '{{if not .Standard}}{{.ImportPath}}{{end}}'
github.com/elcuervo/minimalweather/minimalweather
github.com/elcuervo/minimalweather/pages
github.com/elcuervo/minimalweather/routes
```

What rule should I use to determine which if these import paths I actually want in my Godeps file considering they are the same repository? I've "solved" this by having `gpm bootstrap` only consider top level packages (I.E: where the import path corresponds to a $GOPATH/src/<import_path> directory).

This is imperfect because it will ignore Go packages that don't have a top-level package, maybe a repository has a list of subpackages which you import but if the repo root itself is not a package then it will be ignored.

I **think** this should not be a big issue because in practice repositories that don't have a top-level package tend to be applications, not libraries, and so you're not likely to be importing those, but it does make this feature imperfect in gpm for some use cases without a doubt.

### Summary

This feature provides a nicer user experience, but adds a non-trivial amount of complexity and is imperfect. Should it be added?