Correctly return matched pathspec when passing "*" or "*".

This issue was detected during implementation of libgit2/libgit2sharp/pull/343

**Context**
`git_pathspec_init` is the function used to initialize a `git_vector` of pathspecs from a list of pathspecs passed from the client. However, if the list of pathspecs passed by the client is not deemed interesting (through the use of `git_pathspec_is_interesting`), then an empty vector is initialized.

What is considered an **un**interesting list of pathspec?
- a NULL or empty list
- if the client passed only one pathspec, and if this pathspec is `(!str || !str[0] || (!str[1] && (str[0] == '*' || str[0] == '.')))`

Later on, when the vector of pathspecs is used in `git_pathspec_match_path`, one of the early exit branch is

    if (!vspec || !vspec->length)
        return true;

This means that we consider the pathspec a match, but we don't return **which** pathspec matched (it could be either '*' or '.') in the `matched_pathspec` out parameter.

**What does it mean for libgit2sharp (and other clients?)**
When passing just '*' or '.', the diff process does not correctly notify which pathspec matched the diffed file (notifying was introduced in libgit2/libgit2#1249).

**Ways to fix it**
If it can help, I'm willing to tackle this issue, but I would like to check first with you if this is a valid issue (we could also say it's up to the clients to handle those cases, even if it's still a bit painful IMO), and if yes, what is the preferred way to solve it.

Here are the ways I can think of:
- 1st proposal (Included in the PR at the moment): just before calling the notify callback, get the matched pathspec if it exists, or fallback to the one that was passed by the user if it doesn't ("*" and "." cases).
- 2nd proposal: remove the `git_pathspec_is_interesting` shortcut. It means removing an existing optimization, but I don't think this will have an impact on performance (no numbers to back up this claim, tell me if you want/need some)