When adding an index entry "a/b/c" while an index entry "a/b" already
exists, git will happily remove "a/b/c" and only add the new index
entry:

    $ git init test
    Initialized empty Git repository in /tmp/test.repo/test/.git/
    $ touch x
    $ git add x
    $ rm x
    $ mkdir x
    $ touch x/y
    $ git add x/y
    $ git status
    A x/y

The other way round, adding an index entry "a/b" with an entry "a/b/c"
already existing is equivalent, where git will remove "a/b/c" and add
"a/b".

In contrast, libgit2 will currently fail to add these properly and
instead complain about the entry appearing as both a file and a
directory. This is a programming error, though: our current code already
tries to detect and, in the case of `git_index_add`, to automatically
replace such index entries. Funnily enough, we already remove the
conflicting index entries, but instead of adding the new entry we then
bail out afterwards. This leaves callers with the worst of both worlds:
we both remove the old entry but fail to add the new one.

The root cause is weird semantics of the `has_file_name` and
`has_dir_name` functions. While these functions only sound like they are
responsible for detecting such conflicts, they will also already remove
them in case where its `ok_to_replace` parameter is set. But even if we
tell it to replace such entries, it will return an error code.

Fix the error by returning success in case where the entries have been
replaced. Fix an already existing test which tested for wrong behaviour.
Note that the test didn't notice that the resulting tree had no entries.
Thus it is fine to change existing behaviour here, as the previous
result could've let to silently loosing data. Also add a new test that
verifies behaviour in the reverse conflicting case.