Add best_direction() helper for canonical (kind, field) directions

[iskandr]

Closes #211.

Summary

Surfaces the canonical "best direction" of a prediction field — whether higher or lower is better — as a queryable API alongside Kind and kind_support(). Half of this was already implicit in PeptideResult._best_by_score (max for score) and ._best_by_rank (min for percentile_rank); the new module-level best_direction(kind, field) makes the convention explicit and extends it to value, whose direction is kind-dependent (IC50 nM for pMHC_affinity → min; half-life for pMHC_stability → max).

This PR also promotes the previously-private _best_by_* helpers to a public, direction-aware API on PeptideResult.

New API in mhctools.pred (re-exported from mhctools)

FIELD_BEST_DIRECTIONS = {"score": "max", "percentile_rank": "min"}
VALUE_BEST_DIRECTIONS = {
    Kind.pMHC_affinity: "min",   # IC50 nM
    Kind.pMHC_stability: "max",  # half-life
}

def best_direction(kind, field) -> str: ...

class PeptideResult:
    def best_by(self, kind, field) -> Optional[Prediction]: ...
    def best_by_score(self, kind) -> Optional[Prediction]: ...
    def best_by_rank(self, kind) -> Optional[Prediction]: ...
    def best_by_value(self, kind) -> Optional[Prediction]: ...

best_direction() raises ValueError for field='value' on a kind without a registered direction, with a pointer to the table — the safer "fail loud" path for new value-bearing kinds.

The existing convenience accessors (affinity, presentation, best_affinity_by_rank, …) now route through the public methods. Internal _best_by_score / _best_by_rank are removed in favor of the unified best_by.

Why

Downstream aggregators (openvax/topiary#160's BestAlleleField; vaxrank tier signals) need this to do "best across alleles" or "best across methods" without replicating the table. Same architectural pattern as #210 — per-kind metadata next to Kind.

Behavior change to note

best_*_by_rank accessors now fall back to allele-less rank predictions when no allele-bearing rank prediction of that kind exists, matching the existing fallback in best_* (score) accessors. The old _best_by_rank returned None in that case. In practice rank predictions always come with an allele, so this should be invisible — but downstream consumers relying on "no allele ⇒ None for rank" should be aware. Pinned by test_best_by_rank_falls_back_to_allele_less.

Test plan

• pytest tests/test_pred.py — 17 new tests covering: field-default constants, kind-specific value directions, best_direction() happy path for score/rank/value, value on unregistered kind raises, unknown field raises, accepts string-or-Kind input, best_by_* happy paths for all three fields, best_by_value raises for unregistered kinds, None-skipping, allele-less fallback for both score and rank, missing-kind returns None, string-kind input on best_by.
• Full unit suite: 373 passed, 7 skipped (Python 3.10/3.11/3.12 + integration-netmhc all green in CI).

Bumps to 3.14.1.