make it easier to configure auto-deploy for *upstream* repo

[mykmelez]

The configure command assumes that you want to auto-deploy merges to the master branch on the origin remote.

But for projects with multiple contributors, it's common for a user to fork the original repo and clone their fork, such that the origin remote points to their fork, and then create an upstream remote for the original repo, as described in GitHub's Fork A Repo documentation.

And it's actually more interesting to configure auto-deploy for the original, upstream repo, since that's the one in which people will more often merge changes via pull requests and want those merges to trigger auto-deploy.

But it's hard to do that right now. You have to either temporarily rename your remotes so the original remote is named origin (which actually sounds like a better name for it, although it is unconventional) or clone the original remote and configure that clone.

We should make it easier to configure auto-deploy for the upstream repo.

For example, we could prompt the user to choose the remote for which to configure auto-deploy, selecting the upstream remote by default if one is defined.

(A related problem is that you can't configure a repo to auto-deploy both the original repo and a fork, since the encrypted GitHub auth token in .travis.yml is repo-specific, and there can be only one auth token in the Travis build environment variables. But that's a different issue.)

[marco-c]

There's an undocumented option in the gh-pages module that should make this easy: https://github.com/tschaub/gh-pages/blob/ab5a1bef7829bacd95e6034dd8f4354df665f2ba/lib/index.js#L64

[marco-c]

tschaub/gh-pages#24 would allow to do this.

[marco-c]

Fixed by #165.