Added git_stash_apply() and git_stash_pop() APIs

This is a tentative implementation of git_stash_apply() based on the actual Git implementation found at https://github.com/git/git/blob/master/git-stash.sh#L440.

Once you have git_stash_apply(), it's trivial to implement git_stash_pop() so I also added it.
Git implementation of this part is at https://github.com/git/git/blob/master/git-stash.sh#L464 and https://github.com/git/git/blob/master/git-stash.sh#L465. It reads the untracked tree into a temp index, then checks out said index using the `--all` option which doesn't touch at all existing workdir files (see http://git-scm.com/docs/git-checkout-index). Very simple and very clean.

Seems like to implement the equivalent in libgit2, there are 3 choices:
1. Checkout files one by one, which is dead simple and guaranteed to work
2. Add a new option to `git_checkout_` to support an equivalent mode to `git checkout-index --all`
3. Attempt to merge the current index tree (which can be in any state) with the untracked tree, check out the result and hope to cover potential edge cases

To me, the right solution here is 2 as it matches exactly the native Git behavior, makes the implementation of `git_stash_apply()` simple and clean and it even adds a missing checkout behavior to libgit2. That's not something I can implement however (maybe you or @carlosmn can do it in case it's a trivial change?). So that leaves us 1 or 3 in the meantime.

Although I understand how 3 works in theory, I'm concerned about edge cases since we are now making assumptions on the state of things with HEAD, index and tree merging instead of simply dealing with the workdir. Unless I'm missing something, 3 is not less code, not really conceptually simpler and not faster and than 1, but is however potentially less robust and has more failure points. We might even need more test cases. So I don't see the benefit of doing this over 1.

That said, if you have a practical implementation of `apply_untracked()` to suggest and you're pretty confident it will handle all possible state combinations of HEAD / index / workdir properly, then I'm happy to copy-paste it in :)