We've been using EINVALIDSPEC for a while to mean this, but that name
is too specific. Introduce this to be more explicit.

We do not error on "merge conflicts"; on the contrary, merge conflicts
are a normal part of merging.  We only error on "checkout conflicts",
where a change exists in the index or the working directory that would
otherwise be overwritten by performing the checkout.

This *may* happen during merge (after the production of the new index
that we're going to checkout) but it could happen during any checkout.

This can be used by tools to show mesages about failing to communicate
with the server. The error message in this case will often contain the
server's error message, as far as it managed to send anything.

Walk up the tree to mkdir, which is less immediately efficient,
but allows us to look at intermediate directories that may need
attention.

There are some combination of objects and target types which we know
cannot be fulfilled. Return EINVALIDSPEC for those to signify that there
is a mismatch in the user-provided data and what the object model is
capable of satisfying.

If we start at a tag and in the course of peeling find out that we
cannot reach a particular type, we return EPEEL.

Already cherry-picked commits should not be re-included.  If all changes
included in a commit exist in the upstream, then we should error with
GIT_EAPPLIED.

Introduce `git_rebase` to set up a rebase session that can
then be continued.  Immediately, only merge-type rebase is
supported.

If the certificate validation fails (or always in the case of ssh),
let the user decide whether to allow the connection.

The data structure passed to the user is the native certificate
information from the underlying implementation, namely OpenSSL or
WinHTTP.

Introduce this error code to signal an authentication failure.