This fixes:

    fatal: Cannot setup tracking information; starting point 'BRANCH' is not a branch.

if the remote refspec is set up to only fetch specific branches and NOT
like the default `+refs/heads/*:refs/remotes/origin/*`.

I don't understand why would git, after fetching into
`refs/remotes/origin/BRANCH`, complain that `origin/BRANCH` is not a
branch, but there we have it. Setting up upstream tracking manually
works around this problem.

When checking out a PR, use its head ref for the default branch name so
that `git push` works by default to push commits back to the PR.

When checking out a pull request that doesn't match an existing remote,
this sets the branch's remote and merge configuration fields. If the
pull request is modifiable by the maintainer, it uses the SSH URL to
that you can push to the pull request.

Fixes #1293

When there is already a git remote for the head repo of a PR to be
checked out, fetch the corresponding branch from that remote instead of
fetching the special `refs/pull/XY/head` ref.

This sets up a pull/push workflow for branches that the user might have
write access to and wishes to collaborate on.

Fixes #1238

In case when the PR's head and base repositories are the same, check out
the new branch in a way that sets up push workflow to the same branch.

    git fetch origin +refs/heads/fixes:refs/remotes/origin/fixes
    git checkout -b fixes --track origin/fixes

The remote needs to match the base project from the pull request.

This is so the tags from the automatically-added remote (typically
someone's fork) don't spill in and mix with the current tags.

To obtain the owner/fork-name combo, instead of reading it from "label"
field from the PR response simply read from `Head.Ref` and
`Head.Repo.Owner.Name` instead. This is because label is meant to be
human-readable, isn't well-documented in GitHub API docs and is unclear
when it contains two components (delimited by `:`) and when it contains
only one.

Start reading the `Head.Repo.Name` property from API payload to
determine the name of the forked repo which might not match the name of
the base repo.

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

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