Walk only as far as the common ancestors of uninteresting commits

Treat an empty list of refspecs the same as a NULL value.

Implement git-describe

config: Handle multiple spaces that follow a configuration value and precede a comment char

Fix README.md

Trivial fixups

Introduce reference transactions

Implement opportunistic ref updates

This leaves space for future expansion to locking other resources
without having to change the API for references.

Add `git_merge_bases_many`

This should have been included when implementing the feature but was
missed.

If there have been no pushes, we can immediately return ITEROVER. If
there have been no hides, we must not run the uninteresting pre-mark
phase, as we do not want to hide anything and this would simply cause us
to spend time loading objects.

This introduces a phase at the start of preparing a walk which pre-marks
uninteresting commits, but only up to the common ancestors.

We do this in a similar way to git, by walking down the history and
marking (which is what we used to do), but we keep a time-sorted
priority queue of commits and stop marking as soon as there are only
uninteresting commits in this queue.

This is a similar rule to the one used to find the merge-base. As we
keep inserting commits regardless of the uninteresting bit, if there are
only uninteresting commits in the queue, it means we've run out of
interesting commits in our walk, so we can stop.

The old mark_unintesting() logic is still in place, but that stops
walking if it finds an already-uninteresting commit, so it will stop on
the ones we've pre-marked; but keeping it allows us to also hide those
that are hidden via the callback.

The old separation was due to the old merge-base finding, so it's no
longer necessary.

These store merge-base information which is only valid for a single run.

hashsig: Export as a `sys` header

Since this isn't under sys/ we need to have it included in the main
git2.h file.

This fixes #2551.

The stash is implemented as the refs/stash reference and its reflog. In
order to modify the reflog, we need avoid races by making sure we're the
only ones allowed to modify the reflog.

We achieve this via the transactions API. Locking the reference gives us
exclusive write access, letting us modify and write it without races.

A transaction allows you to lock multiple references and set up changes
for them before applying the changes all at once (or as close as the
backend supports).

This can be used for replication purposes, or for making sure some
operations run when the reference is locked and thus cannot be changed.

This will be used by the transaction code.

When a list of refspecs is passed to fetch (what git would consider
refspec passed on the command-line), we not only need to perform the
updates described in that refspec, but also update the remote-tracking
branch of the fetched remote heads according to the remote's configured
refspecs.

These "fetches" are not however to be written to FETCH_HEAD as they
would be duplicate data, and it's not what the user asked for.

The configured/base fetch refspecs need to be taken into account in
order to implement opportunistic remote-tracking branch updates. DWIM
them and store them in the struct, but don't do anything with them yet.

We can only DWIM when we've connected to the remote and have the list of
the remote's references. Adding or setting the refspecs should not
trigger an attempt to DWIM the refspecs as we typically cannot do it,
and even if we did, we would not use them for the current fetch.

This lets us test this bit as well as getting closer to what they were
trying to do.