This is an experimental addition to add ** support to fnmatch
pattern matching in libgit2.  It needs more testing.

Improve submodule cache management

Retry committing locked files on error

I wrote this stuff a while ago and forgot to write tests.  Wanted
to do so now to wrap up the PR and immediately found problems.

The base for the relative urls is determined as follows, with descending
priority:

- remote url of HEAD's remote tracking branch
- remote "origin"
- workdir

This follows git.git behaviour

Const correctness!

Handle an upstream branch for an unborn one

Skip tests on Clar

When the current branch is unborn, git will still mark the current
branch's upstream for-merge if there is an upstream configuration. The
only non-constrived case is cloning from an empty repository which then
gains history. origin's master should be marked for-merge.

In order to do this, we cannot use the high-level wrappers that expect a
reference, as we may not have one. Move over to the internal ones that
expect a reference name, which we do have.

Cloning from an empty repo must set master's upstream to origin's
master, even if neither of them exist.

Fetching from a non-empty origin must then mark the master branch
for-merge. This currently fails.

Fix submodule_is_config_only's return value

No need to find merge base.

Correct a stale reference to GIT_EBAREINDEX

Per @carlosmn, git_index_add is now named git_index_add_bypath.

Skip untracked contained repo contents even with gitlink files

One blame test replies on being run from within the libgit2
repository to leverage having a longer history to play with, but
some bundled versions of libgit2 don't have the whole libgit2
history.  This just skips that test if the repository can't be
opened.

When doing a diff for use in status, we should never show the
content of a git repository contained inside another one.  The
logic to do this was looking for a .git directory and so when a
gitlink plain .git file was used, it was failing to exclude the
directory content.

There was a little bug where the submodule cache thought that the
index date was out of date even when it wasn't that was resulting
in some extra scans of index data even when not needed.

Mostly this commit adds a bunch of new tests including adding and
removing submodules in the index and in the HEAD and seeing if we
can automatically pick them up when refreshing.

With the new submodule cache validity checks, we generally don't
need to call git_submodule_reload_all to have up-to-date submodule
data.  Some tests are still calling it where I want to actually
test that it can be called safely and doesn't break anything, but
mostly it is not needed.

This also expands some of the existing submodule tests to cover
some variants on the behavior that was already being tested.

Wrote tests that try adding, removing, and updating the name of
submodules which showed a number of problems with how we account
for changes when incrementally updating the submodule info.  Most
of these issues didn't exist before because reloading would always
blow away the old submodule data.

This improvement the management of the lock around submodule cache
updates slightly, using the lock to make sure that foreach can
safely make a snapshot of all existing submodules and making sure
that git_submodule_add_setup also grabs a lock before inserting
the new submodule.  Cache initialization / refresh should already
have been holding the lock correctly as it adds submodules.

This makes it so that git_submodule_reload_all will actually only
reload changed items unless the `force` flag is used.

When forcing cache flushes or reload, etc., it is easier to keep
track of intent using enums instead of plain bools.  Also, this
fixes a bug where the cache was not being properly refreshes by
a git_submodule_reload_all.

This makes submodule cache refresh actually look at the timestamps
from the data sources for submodules and reload as needed if they
have changed since the last refresh.

This takes the old submodule cache which was just a git_strmap
and makes a real git_submodule_cache object that can contain other
things like a lock and timestamp-ish data to control refreshing of
submodule info.

This allows you to use a --repeat option to run status over and
over and see how the output changes as you make local directory
changes without reopening the git_repository object each time.

Also, adds a flag to explicitly list the submodules before status.

Turns out there was already a helper to do what I wanted to do,
so I just made it so that I could use it for sync and switched to
that instead.

This fixes `git_submodule_sync` to correctly update the remote URL
of the default branch of the submodule along with the URL in the
parent repository config (i.e. match core Git's behavior).

Also move some useful helper logic from the submodule code into
a shared config API `git_config__update_entry` that can either set
or delete an entry with constraints like not overwriting or not
creating a new entry.  I used that helper to update a couple other
places in the code.

There are a few places where we need to join three strings to
assemble a path.  This adds a simple join3 function to avoid the
comparatively expensive join_n (which calls strlen on each string
twice).

In-memory packing backend

Fix submodule sort order during iteration