We used to assume a refspec would only have an asterisk in the middle of
their respective pattern. This has not been a valid assumption for some
time now with git.

Instead of assuming where the asterisk is going to be, change the logic
to treat each pattern as having two halves with a replacement bit in the
middle, where the asterisk is.

When transforming a non-pattern refspec, we simply need to copy over the
opposite string. Move that logic up to the wrapper so we can assume a
pattern refspec in the transformation function.

This allows us to add e.g. "HEAD" as a refspec when none are given
without overwriting the user's data.

Relax the ONELEVEL ref naming rules so the refspec parsing code can
ask for 'master' to be considered valid.

It used to be separate as an attempt to make the querying easier, but
it didn't work out that way, so put all the data together.

Add git_refspec_string() as well to get the original string, which is
now stored alongside the independent parts.

A remote can have a multitude of refspecs. Up to now our git_remote's
have supported a single one for each fetch and push out of simplicity
to get something working.

Let the remotes and internal code know about multiple remotes and get
the tests passing with them.

Instead of setting a refspec, the external users can clear all and add
refspecs. This should be enough for most uses, though we're still
missing a querying function.