Fix compatibility with git when run with no arguments

Fix issue/PR labels output in no-color mode

Fixes this error:

    $ hub --git-dir=.git
    git: '' is not a git command. See 'git --help'.

Instead, help text is shown just like with normal git.

Right now this doesn't push to fork, but ideally it should if the person
doesn't have the permissions to push to upstream.

Allow repository names that start with a dash character

These are allowed on GitHub.

Linuxbrew is available on linux and WSL

[ci skip]

Fixes #2054 [ci skip]

Fixes #2066

Make `checkout` work independently of remote refspec

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.

Add pull-request --no-edit flag to zsh completion

Documentation of install on Debian (sid/buster)

Squash on merge

Ref. #2043

Fixes #718 by documenting that the package is in the official repository now, or perhaps there is also a need for a package for the current stable Debian version.

List PR "Draft" state using the `--format` string

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

Have commands with rich output respect the `--color` flag

Add FreeBSD installation instructions

Make man pages parseable with `whatis`

- default: `--color=auto`
- `--color` is equivalent to `--color=always`
- `--color=never` disables color for TTYs

Outputs the "NAME" section in roff format to fix the following:

    mandb: warning: ... whatis parse for hub-alias(1) failed

Fixes https://github.com/github/hub/issues/2025

Fixes https://github.com/github/hub/issues/2036

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.