Recursive Merge

When building a recursive merge base, allow conflicts to occur.
Use the file (with conflict markers) as the common ancestor.

The user has already seen and dealt with this conflict by virtue
of having a criss-cross merge.  If they resolved this conflict
identically in both branches, then there will be no conflict in the
result.  This is the best case scenario.

If they did not resolve the conflict identically in the two branches,
then we will generate a new conflict.  If the user is simply using
standard conflict output then the results will be fairly sensible.
But if the user is using a mergetool or using diff3 output, then the
common ancestor will be a conflict file (itself with diff3 output,
haha!).  This is quite terrible, but it matches git's behavior.

Use annotated commits to act as our virtual bases, instead of regular
commits, to avoid polluting the odb with virtual base commits and
trees.  Instead, build an annotated commit with an index and pointers
to the commits that it was merged from.

When there are more than two common ancestors, continue merging the
virtual base with the additional common ancestors, effectively
octopus merging a new virtual base.

When the commits to merge have multiple common ancestors, build a
"virtual" base tree by merging the common ancestors.

Add a simple recursive test - where multiple ancestors exist and
creating a virtual merge base from them would prevent a conflict.

Memleak fixes

checkout: only consider nsecs when built that way

When examining the working directory and determining whether it's
up-to-date, only consider the nanoseconds in the index entry when
built with `GIT_USE_NSEC`.  This prevents us from believing that
the working directory is always dirty when the index was originally
written with a git client that uinderstands nsecs (like git 2.x).

Fix <0 unsigned comparison (stat.st_size should be an off_t)

Fix some warnings

Stat fixes

repository: distinguish sequencer cherry-pick and revert

These are not quite like their plain counterparts and require special handling.

Racy fixes for writing new indexes

Protect windows SYSDIR when running tests

Don't put the configuration in a subdir of the sandbox named
`config`, lest some tests decide to create their own directory
called `config`.  Prefix with some underscores for uniqueness.

Query the `GIT_CONFIG_LEVEL_PROGRAMDATA` location when setting it up
for tests, in case the test runner has sandboxed it.

Allow users to set the `git_libgit2_opts` search path for the
`GIT_CONFIG_LEVEL_PROGRAMDATA`.  Convert `GIT_CONFIG_LEVEL_PROGRAMDATA`
to `GIT_SYSDIR_PROGRAMDATA` for setting the configuration.

Ensure that `git_index_read_index` clears the uptodate bit on
files that it modifies.

Further, do not propagate the cache from an on-disk index into
another on-disk index.  Although this should not be done, as
`git_index_read_index` is used to bring an in-memory index into
another index (that may or may not be on-disk), ensure that we do
not accidentally bring in these bits when misused.