No files merged may result in bogus merge conflict error

So I found an interesting edge-case here: When cherry-picking a commit which has previously been applied and having untracked files in the working directory always resulted in a merge conflict error.

The reason for this is that even though we didn't merge any changes (they already exist in the index), we were passing 0 as the count parameter to ```git_diff_index_to_workdir```, resulting in all of the untracked files being reported as conflicted.

I've added a test case for this, the most natural place I found was using ```git_cherrypick``` as this is the most likely place you'll hit the problem.
I don't really care for this.  "1 uncommitted change (0 in the index, 1 in the workdir)" seems like a weird message, sort of on par with poorly pluralizing "1 uncommitted changes" or something.  But it's really information overkill for (say) Visual Studio users.

Long-term we need a callback for conflicts here.  I've been meaning to do that but have not yet gotten around to it.

I think we should drop this change and if you want this data then we should add the callback.  If you don't really care about the data right now then I think this error message is less helpful than before.