Use the new-style index names throughout our own codebase.

Use legitimate (existing) object IDs in tests so that we have the
ability to turn on strict object validation when running tests.

Test that on platforms without `core.symlinks`, we preserve symlinks
in `git_index_add_bypath`.  (Users should correct the actual index
entry's mode to change a link to a regular file.)

When we do not trust the on-disk mode, we use the mode of an existing
index entry.  This allows us to preserve executable bits on platforms
that do not honor them on the filesystem.

If there is no stage 0 index entry, also look at conflicts to attempt
to answer this question:  prefer the data from the 'ours' side, then
the 'theirs' side before falling back to the common ancestor.

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`.

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.