When `git_repository__cvar` fails we may end up with a
`ignorecase` value of `-1`. As we subsequently check if
`ignorecase` is non-zero, we may end up reporting that data
should be removed when in fact it should not.

Err on the safer side and set `ignorecase = 0` when
`git_repository__cvar` fails.

Now that iterators do not return `GIT_ENOTFOUND` when advancing
into an empty directory, we do not need a special `advance_into_or_over`
function.

Drop some of the layers of indirection between the workdir and the
filesystem iterators.  This makes the code a little bit easier to
follow, and reduces the number of unnecessary allocations a bit as
well.  (Prior to this, when we filter entries, we would allocate them,
filter them and then free them; now we do the filtering before
allocation.)

Also, rename `git_iterator_advance_over_with_status` to just
`git_iterator_advance_over`.  Mostly because it's a fucking long-ass
function name otherwise.

Many code paths in checkout need the final, full on-disk path of the
file they're writing.  (No surprise).  However, they all munge the
`data->path` buffer themselves to get there.  Provide a nice helper
method for them.

Plus, drop the use `git_iterator_current_workdir_path` which does the
same thing but different.  Checkout is the only caller of this silly
function, which lets us remove it.

Disambiguate the reset and reset_range functions.  Now reset_range
with a NULL path will clear the start or end; reset will leave the
existing start and end unchanged.

win32: allow us to read indexes with forbidden paths on win32

Allow `git_index_read` to handle reading existing indexes with
illegal entries.  Allow the low-level `git_index_add` to add
properly formed `git_index_entry`s even if they contain paths
that would be illegal for the current filesystem (eg, `AUX`).
Continue to disallow `git_index_add_bypath` from adding entries
that are illegal universally illegal (eg, `.git`, `foo/../bar`).

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