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

Racy fixes for writing new indexes

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.

The uptodate bit should have a lifecycle of a single read->write
on the index.  Once the index is written, the files within it should
be scanned for racy timestamps against the new index timestamp.

Keep track of entries that we believe are up-to-date, because we
added the index entries since the index was loaded.  This prevents
us from unnecessarily examining files that we wrote during the
cleanup of racy entries (when we smudge racily clean files that have
a timestamp newer than or equal to the index's timestamp when we
read it).  Without keeping track of this, we would examine every
file that we just checked out for raciness, since all their timestamps
would be newer than the index's timestamp.

When examining paths that are racily clean, do a single index->workdir
diff over the entirety of the racily clean files, instead of a diff
per file.

git_index_entry__init_from_stat: set nsec fields in entry stats

Improve error messages when dirs prevent ref/reflog creation