git_patch_from_diff may return a NULL patch without an error

[jorio]

Diff.__getitem__ used to assume (incorrectly) that when git_patch_from_diff returns 0 (success), it also creates a valid git_patch.

However, per the docs for git_patch_from_diff, "For an unchanged file (...) no git_patch will be created, the output will be set to NULL".

In practice, git_patch_from_diff doesn't always return a NULL patch if the file is unchanged. However, I found a scenario involving CRLF filters that consistently triggers this edge case (success code with NULL patch).

This PR makes Diff.__getitem__ return None in this case. This prevents passing NULL to wrap_patch, which would cause undefined behavior in release builds (because this assertion would be bypassed).

[jorio]

Ah, the new mypy checks failed (they weren't set up to run automatically in my fork before I submitted the PR) because Diff.__getitem__ may now return None, and many unit tests just assume that they can use diff[number] to get a valid patch.

Some thoughts:

• Should Diff.__getitem__ raise an exception if libgit2 declines to create the patch? This way, we wouldn't have to return None, but iterating on a Diff may be interrupted halfway through by an exception.
• Or, should we put the burden on the user to check that every single patch gotten via Diff[] or Diff.__iter__ is not None?

[jdavid]

• Should Diff.getitem raise an exception if libgit2 declines to create the patch? This way, we wouldn't have to return None, but iterating on a Diff may be interrupted halfway through by an exception.
• Or, should we put the burden on the user to check that every single patch gotten via Diff[] or Diff.iter is not None?

The second one is better in my opinion, the way it's already in this PR.
The first one would require the user to handle it as well, but with a try/except, which is worse in my opinion.