remote: accept a repository and remote name for deletion

We don't need the remote loaded, and the function extracted both of
these from the git_remote in order to do its work, so let's remote a
step and not ask for the loaded remote at all.

This fixes #2390.

When a list of refspecs is passed to fetch (what git would consider
refspec passed on the command-line), we not only need to perform the
updates described in that refspec, but also update the remote-tracking
branch of the fetched remote heads according to the remote's configured
refspecs.

These "fetches" are not however to be written to FETCH_HEAD as they
would be duplicate data, and it's not what the user asked for.

This lets us test this bit as well as getting closer to what they were
trying to do.

With opportunistic ref updates, git has introduced the concept of having
base refspecs *and* refspecs that are active for a particular fetch.

Let's start by letting the user override the refspecs for download.

Restrict which refs can be the default branch

When the fetch refspec does not include the remote's default branch, it
indicates an error in user expectations or programmer error. Error out
in that case.

This lets us get rid of the dummy refspec which can never work as its
zeroed out. In the cases where we did not find a default branch, we set
HEAD detached immediately, which lets us refactor the "normal" path,
removing `found_branch`.

If the remote does not advertise HEAD, then it is unborn and we cannot
checkout that branch. Handle it the same way as an empty repo.

When cloning, we may be asking for a particular branch or subset of
branches. Make sure we test for that.