git_fetch_options was missing from the API docs because it lacked a
documentation comment above the struct declaration.
I used the git_checkout_options docstring as a template.

Also fixes a typo in git_remote_prune_refs (remote, not reamote).

Removing a reflog upon ref deletion is something which only some
backends might wish to do. Backends which are database-backed may wish
to archive a reflog, log-based ones may not need to do anything.

This is to be returned when the operation which the user asked for is
not possible to do on a directory.

These functions are available on the public API but don't have any
documentation, so they don't appear on the API reference. Fix that.

The function was removed, but its declaration and changelog entry about
its removal were forgotten.

The comment in the test doesn't make any sense as the function doesn't
exist anymore, so get rid of it as well.

Allow custom filters with wildcard attributes, so that clients
can support some random `filter=foo` in a .gitattributes and look
up the corresponding smudge/clean commands in the configuration file.

Fallback describes the mechanism, while unspecified explains what the
user is thinking.

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

We currently recommend using `git_buf_grow` in order to make a buffer
make an owned copy of the memory it points to. This is not behaviour we
should encourage, so remove this recommendation.

The function itself is not changed, as we need to remain compatible, but
it will be changed not to allow usage on borrowed buffers.

The information is exposed by curl for some crypto libraries in the form
of name:content strings. We can't do much more than return this
information.

If the stream claims to support this feature, we can let the transport
set the proxy.

We also set HTTPPROXYTUNNEL option so curl can create a tunnel through
the proxy which lets us create our own TLS session (if needed).

These are not useful anymore, as we don't affect the instance's
configuration.

We no longer have any setters which affect an instance, so
`git_submodule_save()` is no longer relevant.

With this one, we can get rid of the edit_and_save test.

Similarly to the other ones. In this test we copy over testing
`RECURSE_YES` which shows an error in our handling of the `YES` variant
which we may have to port to the rest.

Moving on with the removal of runtime-changing variables, the update
setting for a remote is whatever it was when it was looked up.

This lets us specify in the status call which ignore rules we want to
use (optionally falling back to whatever the submodule has in its
configuration).

This removes one of the reasons for having `_set_ignore()` set the value
in-memory. We re-use the `IGNORE_RESET` value for this as it is no
longer relevant but has a similar purpose to `IGNORE_FALLBACK`.

Similarly, we remove `IGNORE_DEFAULT` which does not have use outside of
initializers and move that to fall back to the configuration as well.

As submodules are becomes more like values, we should not let a status
check to update its properties. Instead of taking a submodule, have
status take a repo and submodule name.

Instead of affecting a particular instance, make it change the
configuration.

This allows the user to look up fields which we don't parse in libgit2,
and allows them to access gpgsig or mergetag fields if they wish to
check the signature.

We currently use a timetamp to check whether an index file has been
modified since we last read it, but this is racy. If two updates happen
in the same second and we read after the first one, we won't detect the
second one.

Instead read the SHA-1 checksum of the file, which are its last 20 bytes which
gives us a sure-fire way to detect whether the file has changed since we
last read it.

As we're now keeping track of it, expose an accessor to this data.

Introduce a new binary diff callback to provide the actual binary
delta contents to callers.  Create this data from the diff contents
(instead of directly from the ODB) to support binary diffs including
the workdir, not just things coming out of the ODB.

`git_filter_list_contains` can be used to query a filter list to
determine if a given filter will be run.

This was forgotten when the feature was implemented.

A remote's URLs are now modified according to the url.*.insteadOf
and url.*.pushInsteadOf configurations. This allows a user to
replace URL prefixes by setting the corresponding keys. E.g.
"url.foo.insteadOf = bar" would replace the prefix "bar" with the
new prefix "foo".

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.

Mark the `old_file` and `new_file` sides of a delta with a new bit,
`GIT_DIFF_FLAG_EXISTS`, that introduces that a particular side of
the delta exists in the diff.

This is useful for indicating whether a working directory item exists
or not, in the presence of a conflict.  Diff users may have previously
used DELETED to determine this information.

It's not always obvious the mapping between stage level and
conflict-ness.  More importantly, this can lead otherwise sane
people to write constructs like `if (!git_index_entry_stage(entry))`,
which (while technically correct) is unreadable.

Provide a nice method to help avoid such messy thinking.

When diffing against an index, return a new `GIT_DELTA_CONFLICTED`
delta type for items that are conflicted.  For a single file path,
only one delta will be produced (despite the fact that there are
multiple entries in the index).

Index iterators now have the (optional) ability to return conflicts
in the index.  Prior to this change, they would be omitted, and callers
(like diff) would omit conflicted index entries entirely.

When adding a conflict for some path, remove the staged entry.
Otherwise, an illegal index (with both stage 0 and high-stage
entries) would result.

When we moved from acting on the instance to acting on the
configuration, we dropped the validation of the passed refspec, which
can lead to writing an invalid refspec to the configuration. Bring that
validation back.

An anonymous remote is not configured and cannot therefore have
configured refspecs. Remove the parameter which adds this from the
constructor.