The description for --head said it was the head branch instead of head branch.

The `create` and `remote` commands needs to infer the current project
name from the project's directory. Instead of using the current working
directory, which doesn't necessarily match the project's toplevel
directory, use `git rev-parse --show-toplevel` which also respects the
`-C` global flag setting.

Fixes #1105, closes #1114

For git commands that are extended by hub, such as `git remote`, the
final git command would get executed without the git global flags
provided when executing hub in the first place.

This most notably broke the usage of `-C <dir>` flag.

* Use -a or --assignee to filter repo issues list by assignee
* Makes it easier to find pull requests and issues you've been
  assigned to address

Since TAG is provided as argument, the user already knows the tag name
and there's no need to include it (rather clumsily) in the output.

This mimics `git` behavior.

Instead of displaying plain text help, `hub help <command>` will now
search for man pages to display.

* If `man` is available, hub first tries to locate the local
  `../man/hub-<command>.1` file relative to the `hub` executable. If
  found, open it with `man`. If not, execute `man 1 hub-<command>`.

* Otherwise, resort to displaying plain text help.

For compatibility with git, `hub help checkout` will display the help
for git-checkout and there will be no information about hub extensions
to this command.

Now with `hub help hub-checkout`, hub will print the help text from
hub's extension to git-checkout.

- No more `c.Short` property. Instead, the first line of `c.Long`
  property is considered a short command description.

- The `c.Usage` text can now contain multiple lines.

- The new `c.Synopsis()` method renders usage synopsis for humans:

    Usage: hub my-command --arg
           hub my-command --alternative-arg

- The new `c.HelpText()` method renders synopsis + full help text.

Fixes #862

In `hub clone NAME`, "NAME" was previously considered a local resource
if a directory of the same name existed, and the clone command was left
unchanged.

That worked for a while, but some users were surprised that they
couldn't clone their repo named "NAME", only to discover that there was
an unrelated directory "NAME" in the current working directory.

Also, a git bundle is a valid cloneable resource, but is a file and not
a directory.

This refines the detection of cloneable resources. "NAME" is considered
to be locally cloneable if one of the following is true:

- "NAME/.git" exists
- "NAME" is a bare git repo
- "NAME" is a file whose first line includes "git bundle"

In instances where the `SHELL` environment variable is not set, nor is the `-s` parameter set it is not clear what action should occur.  Clarify the error message to make it obvious.

Closes #1065

Untested.

Fixes #896