build: respect environment LDFLAGS and strip the build path

Go 1.10 release notes:

> The go build -asmflags, -gcflags, -gccgoflags, and -ldflags options
> now apply by default only to the packages listed directly on the
> command line. For example, go build -gcflags=-m mypkg passes the
> compiler the -m flag when building mypkg but not its dependencies. The
> new, more general form -asmflags=pattern=flags (and similarly for the
> others) applies the flags only to the packages matching the pattern.
> For example: go install -ldflags=cmd/gofmt=-X=main.version=1.2.3
> cmd/... installs all the commands matching cmd/... but only applies
> the -X option to the linker flags for cmd/gofmt. For more details, see
> go help build.

golang does not natively respect LDFLAGS, but you can pass them on the
command line using -ldflags=-extldflags=...
This is important for distributions, in order to provide common
functionality such as hardening flags.

Also strip the prefixed root source directory from the embedded source
file paths. This is not important information for the debugger, which
should only care about paths relative to $GOPATH, and results in less
build environment metadata leaking into the final binary. (This also
aids in reproducible builds when using different build directories, see
e.g. https://github.com/golang/go/issues/16860)

build: embed reproducible timestamp in manpages

If the environment variable SOURCE_DATE_EPOCH is set in the build
environment, prefer it over the current date when determining the
correct timestamp to use as the date the manpages were built.

See https://reproducible-builds.org/specs/source-date-epoch/

Generate man pages using Go instead of Ruby

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

ui Printf functions: handle errors by dying

Closes #1979, fixes #1560

Replace deprecated Dial with DialContext

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.

Improve `hub create` dealing with an existing "origin" remote

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

Don't choke on literal `%` output from `--format` use

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

Capitalize GitHub in doco