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.

- `%pS`: "open", "draft", "merged", or "closed"
- `%pC`: green, gray, purple, or red

Assume that 4xx responses will be the same given the same request, so
these responses should be subject to caching too.

Avoids caching 403 because that is the status returned when GitHub API
limit is hit.

Continue not caching 5xx responses because they indicate server errors,
so it's possible that a 2nd request of identical parameters succeeds.

Fixes #2022

Statuses are now sorted the same as in the GitHub web interface:

- failing first;
- then pending;
- then success/neutral;
- everything in-between is sorted alphabetically.

Fixes #2021

- HTTP response is now printed on stdout regardless of HTTP status
- No longer print an extra newline after HTTP response body
- No more `Error: HTTP {STATUS}` message on stderr
- hub exits with status 22 instead of 1

Allows sending `api.github.com` OAuth token to all `*.github.com`
subdomains. In case `git.my.org` is an Enterprise instance, this allows
sending the token to `git.my.org` and all of `*.git.my.org`.

- sort query string in cache key
- include "Accept", "Authorization" headers in cache key
- allow caching of `/graphql` responses

This ensures that calling `hub api http://example.com/foo` doesn't
accidentally send the OAuth token for `github.com` to `example.com`.

The API result isn't guaranteed to be sorted case-insensitive, so we
perform the sort in memory before displaying.

5 years ago, in anticipation of an API change, I have made the call to
deprecate issue-to-PR conversion in hub. 4f70dd12

Issue-to-PR conversion was wonky at those times, poorly understood, and
was generating a lot of support requests to hub's issue tracker that I
didn't want to deal with. In most cases, people tried to convert issues
that they have no rights over and they would get a cryptic validation
error in the API response.

Since then, there was a consistent plea from the hub community to keep
this feature as some teams seem to rely on this for their workflows. I
have consulted with other GitHub employees about the stableness of this
feature, and anecdotal evidence suggests that lately there haven't been
as many problems around this as there have been in the past. Also, the
GitHub API v3 will not be getting breaking changes, so it sounds like
this feature is here to stay.

Fixes #1927
Ref. #532, #410, #1806, #1770, #1628

When running `hub pull-request` with this git remote setup:
* origin:   `github.com/myuser/myfork`
* github:   `github.com/owner/repo`
* upstream: `example.com/other-repo`

this error would be shown:

    Aborted: the origin remote doesn't point to a GitHub repository.

The error is both unfortunate (the existence of "upstream" shouldn't
have aborted the whole operation) and misleading (it wasn't the "origin"
remote that was the problem).

This changes `MainProject()` so it skips over non-GitHub remotes until
it finds one that points to a GitHub project.

This changes the `MasterBranch()` implementation to consider upstream
remotes that might be named differently than "origin". The new
`DefaultBranch(remote)` function is now the preferred alternative.

- No longer says "updating git remote", but not actually doing anything
- Shows a helpful warning about "origin" pointing to a possibly unrelated repo

In general, avoid using Printf without a static format string.

This queries by `state=closed` and selects only PRs that have a merged date.

This is for compatibility with git-commit(1)

`remote add` may now query the GitHub API to determine whether the
remote URL should be generated in writeable mode or not.

This allows PR templates to include markdown headers with '#'