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.

The push object knows which remote it's associated with, and therefore
does not need to keep its own copy of the callbacks stored in the
remote.

Remove the copy and simply access the callbacks struct within the
remote.

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.

We always use "update by push".

The signature for the reflog is not something which changes
dynamically. Almost all uses will be NULL, since we want for the
repository's default identity to be used, making it noise.

In order to allow for changing the identity, we instead provide
git_repository_set_ident() and git_repository_ident() which allow a user
to override the choice of signature.

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

There is one well-known and well-tested parser which we should use,
instead of implementing parsing a second time.

The common parser is also augmented to copy the LHS into the RHS if the
latter is empty.

The expressions test had to change a bit, as we now catch a bad RHS of a
refspec locally.