The rest of the logic for what delta to choose is in
`get_best_static_delta_start_for`, so move the logic for skipping
scratch deltas there, too. This makes the handling in `initiate_request`
more straightforward by returning no match when it should be skipped so
that it goes directly into the object pull path.

In e7305bb a heuristic was added that
if a scratch delta exists but you already have a commit on that ref that
an object pull should be preferred. The idea is that if you already have
something on the ref, then it's likely that an object pull require less
data to be fetched than pulling the entire new commit.

However, this doesn't take into account the commit state. If the
existing commit is partial, then it might be better to fetch the scratch
delta. On the other hand, if the existing commit is partial only because
a metadata only pull has been done, then the parent commit might be
normal and then you'd want to prefer an object pull again. Instead of
considering just the HEAD local commit, walk the parents and check if
any of them are normal commits. Only then use an object pull.

If a scratch delta exists and the caller has required static deltas, use
it instead of the heuristic about existing commits.

If a normal commit cannot be found in the history of the current ref,
try to find one by looking at the collection and ref bindings in all the
commits in the repo. This will only work if the remote is using
collection IDs since otherwise just looking at the ref bindings in the
local commits would be ambiguous about what remote the commit came from.
If a normal commit with matching bindings is found, prefer an object
pull.

With this change it's possible to have a partial local HEAD commit (from
a previous metadata only pull, for example) and broken history to a
normal ancestor and correctly use the heuristic that an object pull
should be preferred. This is a common case since user repos are likely
to have missed intervening commits on the same remote ref.