If user passes `origin` as the remote name
pointing to forked repository, it's likely
she wants to rename origin as upstream.

When querying `foo/bar` repo redirects elsewhere, assume that `foo/bar`
is available. Fixes #1685

Scenario: Fork the repository with new remote name specified

Allows the user to choose the remote name for their fork instead of
always using their GitHub username. This is useful for workflows where
folks name the remote for their private fork origin `origin` and
the upstream repo remote is named `upstream`. We happen to use this
workflow at work, because it makes the remote names more predictable and
easy to manage (you always push your new commits to `origin` rather than
a remote name that is dependent on your username).

```
$ git remote -v
upstream	git@github.com:github/hub (fetch)
upstream	git@github.com:github/hub (push)

$ ./bin/hub fork --remote-name=origin
Updating origin
From ssh://github.com/github/hub
 * [new branch]      1.11-stable     -> origin/1.11-stable
 * [new branch]      1.12-stable     -> origin/1.12-stable
 * [new branch]      2.2-stable      -> origin/2.2-stable
 * [new branch]      code-coverage   -> origin/code-coverage
 * [new branch]      gh-pages        -> origin/gh-pages
 * [new branch]      master          -> origin/master
 * [new branch]      travis-packages -> origin/travis-packages
new remote: origin

$ git remote -v
origin	git@github.com:msabramo/hub.git (fetch)
origin	git@github.com:msabramo/hub.git (push)
upstream	git@github.com:github/hub (fetch)
upstream	git@github.com:github/hub (push)
```

I haven't written tests yet, but I can if this is a feature that the
maintainers are amenable to merging...

Also, adopt the new name of the fork more precisely so it's reflected in
the new remote URL. The name of the new git remote is for now *not*
inherited from the returned Repository object for backwards compatibility.

Fixes #1178

Fixes nil reference crash. Fixes #1042.

Fixes #929

GHE is using /api/v3 as the path prefix for all API URLs. There’s one miss case when getting current user.

This is to fix https://github.com/github/hub/issues/660#issuecomment-60757883

When `url.scheme` is changed from "https" to "http" when someone
configured their Enterprise instance to be used over insecure protocol,
the "speedy" implementation changed the port as well, but the stdlib
implementation doesn't. Things would break if someone used hub in an
environment where stdlib URI was already loaded, like for instance from
RubyGems.

Example `~/.config/hub`:

  my.example.org:
  - user: myuser
    oauth_token: mytoken
    protocol: http

Currently there is no way to set `protocol` other than manually editing the
configuration file.

Since we use a test server representing the GitHub API, all requests get
transformed to HTTP in tests. Make a check that the original requests
really was intended to go over HTTPS.

Forking through GitHub's API is asynchronous so there is really no way
of knowning when you can access git objects without polling.
Alternatively, we can establish the state of the fork with its remote
tracking branches and tags by fetching from the "origin" remote and then
changing the remote url to the fork.

Every API request will now declare that it wants v3 by setting
"Accept: application/vnd.github.v3+json".

http://developer.github.com/v3/media/

 - performs a single API call instead of 3
 - simpler handling of parent repo data
 - less brittle implementation

Closes #257, references #146

Enterprise installations don't have a separate subdomain for API
requests such as "api.github.com", but their API endpoints start with
"/api/v3" path.

Fixes #201