On case insensitive platforms, allow `git_index_add` to provide a new
path for an existing index entry.  Previously, we would maintain the
case in an index entry without the ability to change it (except by
removing an entry and re-adding it.)

Higher-level functions (like `git_index_add_bypath` and
`git_index_add_frombuffers`) continue to keep the old path for easier
usage.

On case insensitive systems, when given a user-provided path in the
higher-level index addition functions (eg `git_index_add_bypath` /
`git_index_add_frombuffer`), examine the index to try to match the
given path to an existing directory.

Various mechanisms can cause the on-disk representation of a folder
to not match the representation in HEAD or the index - for example,
a case changing rename of some file `a/file.txt` to `A/file.txt`
will update the paths in the index, but not rename the folder on
disk.

If a user subsequently adds `a/other.txt`, then this should be stored
in the index as `A/other.txt`.

Find the first index entry matching a prefix.

We were missing tests for switching the case-sensitivity of an index
in-memory and then looking up entries in it.

When we pass the path of a repository to `_bypath()`, we should behave
like git and stage it as a `_COMMIT` regardless of whether it is
registered a a submodule.

Similarly to how git itself does it, allow the index update operation to
stage a change in a submodule's HEAD.

This also affects `git_index_add_bypath()` by providing a better error
message and a specific error code when a directory is passed.

Even though the file is empty and thus the size in the entry matches, we
should be able to detect it as a difference.

They fit there much better, even though we often check by diffing, it's
about the behaviour of the index.

This will tell us which numbers we were trying to compare, rather than
just telling us that they're different.

When confronted with a conflict in the index, `git_index_add_all`
should stage the working directory copy.  If there is no file in the
working directory, the conflict should simply be removed.

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 adding a conflict for some path, remove the staged entry.
Otherwise, an illegal index (with both stage 0 and high-stage
entries) would result.

Without this option, we would not be able to catch exec bit changes.

The idea...sometimes, a filemode is user-specified via an
explicit git_index_entry.  In this case, believe the user, always.

Sometimes, it is instead built up by statting the file system.  In
those cases, go with the existing logic we have to determine
whether the file system supports all filemodes and symlinks, and
make the best guess.

On file systems which have full filemode and symlink support, this
commit should make no difference.  On others (most notably Windows),
this will fix problems things like:
* git_index_add and git_index_add_frombuffer() should be believed.
* As a consequence, git_checkout_tree should make the filemodes in
the index match the ones in the tree.
* And diffs with GIT_DIFF_UPDATE_INDEX don't write the wrong filemodes.
* And merges, and probably other downstream stuff now fixed, too.

This makes my previous changes to checkout.c unnecessary,
so they are now reverted.

Also, added a test for index_entry permissions from git_index_add
and git_index_add_frombuffer, both of which failed before these changes.

This function is meant to simulate what git does in the reset command,
so we should include the reflog message in that.

The signature for the reflog is not something which changes
dynamically. Almost all uses will be NULL, since we want for the
repository's default identity to be used, making it noise.

In order to allow for changing the identity, we instead provide
git_repository_set_ident() and git_repository_ident() which allow a user
to override the choice of signature.

git_index_add_frombuffer enables now to store a memory buffer in the odb
and to store an entry in the index directly if the index is attached to a
repository.

Introduce `git_indexwriter`, to allow us to lock the index while
performing additional operations, then complete the write (or abort,
unlocking the index).

We need these directories to exist so cl_git_mkfile() can create the
files we ask it to.

Path validation may be influenced by `core.protectHFS` and
`core.protectNTFS` configuration settings, thus treebuilders
can take a repository to influence their configuration.

The entry_count field is the amount of index entries covered by a
particular cache entry, that is how many files are there (recursively)
under a particular directory.

The current code that attemps to do this is severely defincient and is
trying to count the amount of children, which always comes up to zero.

We don't even need to recount, since we have the information during the
cache creation. We can take that number and keep it, as we only ever
invalidate or replace.

If e.g. the root tree is invalidated, we still want to write out
its children, since those may still have valid cache entries.

Keeping the cache around after read-tree is only one part of the
optimisation opportunities. In order to share the cache between program
instances, we need to write the TREE extension to the index.

Do so, taking the opportunity to rename 'entries' to 'entry_count' to
match the name given in the format description. The included test is
rather trivial, but works as a sanity check.

These test that we invalidate at the right levels and that we remove the
tree cache when clearing the index.