A method to measure code coverage across tests

Go has code coverage tooling for test mode, which temporarily rewrites
the source code to insert annotations which will activate during the
test run and track progress of executed code. Then, upon process
completion, that information is dumped into a coverage report.

We can't use this approach for hub, at least not without substantial
changes. First of all, hub's test coverage is mostly "from the outside",
utilizing Cucumber to invoke the binary with different arguments and
inspect the outputs and result. There are some tests in go, but they are
minimal compared to the cukes.

Second, hub frequently aborts the process on errors via `os.Exit(1)`,
and those scenarios need to be tested too. However, if the process exits
prematurely, the code coverage report will never be generated.

To work around this, I first used the go tool that annotates the source:

    go tool cover -mode=set -var=LiveCoverage myfile.go

This injects `LiveCoverage.Count[pos] = 1` lines at appropriate places
all over the source code, and generates a mapping of line/column
positions in the original source.

Then I rewrite those lines to become a method invocation:

    coverage.Record(LiveCoverage, pos)

The new `Record` method will immediately append the information to a
code coverage report file as soon as it's invoked. This ensures that
there is coverage information even if the process gets aborted.

This approach works the same for go tests as well as for cukes. They all
append to the same file. Finally, the rest of Go tooling is used to
generate an HTML report of code coverage:

    go tool cover -html=cover.out

This avoids polluting the user's home environment.
https://github.com/github/hub/pull/1705#issuecomment-392759921

Previously, when `:` wouldn't appear in the value for `head`, the GitHub
API would ignore the `head` parameter altogether. Now, ensure that
`<OWNER>:` syntax is always populated by adding the default from the
current repository.

Add installation method for archlinux

Create '--no-edit' option for hub pull-request

PR checkout: ensure resulting branch is automatically pushable

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

See ctags-incompatibilities(7)

[ci skip]

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.

Pull Request: look for templates in docs/ too

- show synopsis when 'hub delete' is called without the name of a repo
- printing information about missing rights in the access token in case
  repo deletion fails with HTTP 403

- no more HUB_UNSAFE_DELETE environment variable, use -y/--yes now
- do not check for project before deletion
- only ask for y/n confirmation when deleting

Also, split the pull request template with two newlines in between for
compatibility with GitHub web interface.

Fixes #1714

Closes #1731

Fixes #1748

Set slice length to known number of args

pull-request: Hide Signed-off-by