Remove the special case to initialize Dist->github from a hash

We never use it in real code and it complicates a lot of things.
If you really need that, initialize a Gitpan::Github object
yourself and pass it into the constructor.
Move responsibility for Github into the new Repo class.

Yes, Repo is returning.  Coordinating the Git and Github repositories
is important and complicated, so it deserves its own class.
Gitpan::Dist will just be about feeding releases to Gitpan::Repo.
Move responsibility for Git from Dist into Repo.

Now Repo can control both halves of the repository.
This method is a good idea, but nothing actually uses it!

All the checks for Github existance are inside Gitpan::Github.
Later, Repo might restore this optimization.  Right now, it's
dead code and we need less code.
Move delete_repo from Dist into Repo.

This is exactly the sort of thing Repo should be coordinating.
Add Git->new_or_init

This lets us create a Git repository, or use an existing one, without
creating a Gitpan repo.
Simplify Github::Gitpan by not allowing methods to run on other repos.

That feature was total YAGNI and barely useful even in testing.
It's never used in production code.  It complicated everything
by requiring passing around information already in the object.
Cache Gitpan::Github->exists_on_github

This should reduce the number of API calls while letting the code
be careful about checking if the Github repository exists.
Don't init a Git repo just to destroy it.

The only purpose is to get a Gitpan::Git object to call delete on.
Add Gitpan::Git->is_empty, pull( ff_only => 1 ) and change how push/pull are called.

push() and pull() now take the remote and branch as an option rather than
optional positions.  This allows it to take more options.
Add Gitpan::Repo->prepare_for_commits()

This will get the repository ready to take commits on demand, rather
than doing it as soon as one uses the git accessor.  This does not
prepare the repository for pushing, that's another step.  This is
to avoid prematurely creating a Github repository which is
expensive and can get in the way if it winds up not being used.

If there's both a Git and Github repository already, the goal is to
make sure they have not diverged and to get the local Git repository
caught up with the Github repo.  "git pull --ff-only" takes care
of all of this.  If they have diverged, this is an error which a
human must resolve.
Remove work arounds for $@ being blown away by logging.
Add Gitpan::Git->head.

Just a passthrough to Git::Raw.
Add Gitpan::Github->branch_info

Get information about a branch from the Github API.  Useful to test the
state of the Github repository without having to clone it.

Also increase the default backoff to 4 times.  This is probably more useful
for testing than production as we're not usually working on the same
repository in parallel.
Add Gitpan::Repo->prepare_for_push()

This and prepare_for_commits() will replace the need to prematurely
create Git and Github repos.
Don't create a Github repository when asking for Repo->git

Instead, use the new Repo->prepare_for_commits and Repo->push which will
make sure everything is ready to go on demand.
Test that import_releases() will not create an empty repository.

Some distributions have no importable releases.  This could lead to
creating a Github repository and then doing nothing with it.  This
can then lead to a distribution with the same name, different case,
to fail to import because it thinks there's a clashing repository.

Using reform/ReForm because that is a real pair of clashing
releases.  ReForm has no unskipped releases.

Gitpan::Dist->git now creates a Github repository on demand which
fixes the problem.  I put the check to bail out if there's no releases
earlier to avoid a bogus duplicate repository error.
Merge branch 'issue/91'

For #91