Address #5874: Prefer candidates with allowed hashes

[cjerdonek]

This is a follow-on to PR #6687 that addresses issue #5874 (and the same issue #3634), which is to prefer candidates for install that match a user-provided hash (aka the allowed hashes).

PR #6687 makes this PR possible because it added support for creating a new CandidateEvaluator for each Requirement (since the allowed hashes can vary per requirement).

This PR uses an approach different from PR #6464. Instead of filtering the candidates post hoc inside get_best_candidate() and after sorting by preference, the approach in this PR uses index.py's concept of "applicable" candidates combined with using the sort preference itself to do the choosing. First, it uses the allowed hashes to determine which candidates are applicable: if at least one link has a matching hash, then links with non-matching hashes are considered not applicable and filtered out of consideration (and links with matching hashes or no hash are applicable and so are kept). Otherwise, if no link has a matching hash, the list of applicable links is kept the same and no links are filtered out for hash reasons. Then, in the phase of sorting applicable candidates, links with matching hashes are preferred over links whose hash doesn't match (or that don't have a hash).

In a follow-on PR, I can implement @dstufft's suggestion of logging a warning if a link is more preferred but has no hash listed: #5874 (comment)

[xavfernandez]

Nice and clear 👍

[cjerdonek]

Thanks, @xavfernandez! 😊

[cjerdonek]

Merging so I can work on a couple nice-to-have follow-ups to this.