fetch: add fetch.shallow so pull doesn't fetch every branch on shallow repo - #2412

In a shallow, sparsely checked out clone of a repository with many
branches, plain git pull can take minutes or hang outright, even
though only one branch is actually being worked on.

Add fetch.shallow, off by default. When enabled, a fetch or pull for
a shallow repository that isn't already scoped to specific refs
fetches only the current branch's tracked upstream and the remote's
default branch, instead of every branch the remote has. git pull
ultimately runs such a fetch under the hood, so this fixes pull the
same way. It has no effect once the repository is no longer shallow.

This is opt-in rather than automatic because it changes what a plain
fetch or pull leaves in refs/remotes/<name>/ for anyone who currently
relies on it syncing every branch of a shallow remote, not just the
one they are on. Scoping remote.<name>.fetch by hand already covers
this for a single remote, but that requires knowing the config exists
and applies it permanently, even to branches that are not currently
checked out.

The remote's recorded default branch (remotes/<name>/HEAD) is kept up
to date the same way it always is, only the other branches are
skipped. This works even on the very first fetch from a newly added
remote, before anything from it is tracked yet: the ls-refs
advertisement is narrowed to HEAD, and since the server tells us
directly which branch HEAD points to, that branch is fetched too and
written to refs/remotes/<name>/<branch>, so refs/remotes/<name>/HEAD
resolves correctly right away. Without this, git branch
--set-upstream-to=<remote> could not resolve a bare remote name until
either a full, unscoped fetch happened once, or git remote set-head
--auto was run by hand, both of which this config exists to avoid.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>