Having the setting be different from calling its actions was not a great
idea and made for the sake of the wrong convenience.

Instead of that, accept either fetch options, push options or the
callbacks when dealing with the remote. The fetch options are currently
only the callbacks, but more options will be moved from setters and
getters on the remote to the options.

This does mean passing the same struct along the different functions but
the typical use-case will only call git_remote_fetch() or
git_remote_push() and so won't notice much difference.

It can be useful for the caller to know which update commands will be
sent to the server before the packfile is pushed up. git does this via
the pre-push hook.

We don't have hooks, but as it adds introspection into what is
happening, we can add a callback which performs the same function.

Instead we provide git_remote_upload() and git_remote_update_tips() in
order to have a parallel API for fetching and pushing.

This should make it clearer what the return value implies.

The push cannot be successful if we sent a bad packfile. We should
return an error in that case instead of storing it elsewhere.

Use an unsigned int for the version and add a helper macro so the
code is simplified (and so the error message is a common string).

The basic structure of each function is courtesy of arrbee.