Some fixes to git_index_read_index, which replaces an the contents of one index with another. (But doing so intelligently - so that if the destination index already has a stat cache for some files, those will be maintained if the new index being read has not updated those files.)

There are two important fixes here:

1. Remove the tree cache for new files. We were correctly removing the tree cache when removing files from the index, but not when adding them. (We - of course - should have been invalidating the parent trees when adding a new file.)
2. Clear the error during each file comparison between the two indexes. We may hit GIT_ITEROVER on one of the iterators and we must clear that upon each step, otherwise we may hit a branch that does not update error. (In particular, when there is no dup_entry or add_entry, but there is a remove_entry, we may not clear the GIT_ITEROVER.)

Two minor correctness fixes that are important for indexes that will get persisted to disk:

1. Treat different modes as having updated the files and blow away any stat cache. (We previously checked only the OID.)
2. Update the entry's flags that will be persisted as the on disk path length when duplicating an entry. This is generally done during git_index_add and friends, but during the merge into the new index, we should insist upon its existence.