Upgrade fst to 0.4 and swap memmap for memmap2

[bmesuere]

Clears RUSTSEC-2020-0077. fst 0.3 pulls in memmap 0.6, which is unmaintained; fst 0.4 no longer does its own memory mapping, so we do it with memmap2 instead.

The change

Map::from_path and Map::from_bytes are gone in 0.4, replaced by a generic Map::new over anything AsRef<[u8]>. The two ways of loading an index therefore produce different types, which the old if/else cannot express. That choice moved into utils::load_fst behind a small enum, instead of being repeated in four commands — which also shrinks each call site to one line.

Index compatibility

This is the part worth checking before merging, and it is asymmetric. I built the same TSV with both versions and cross-read them:

	reads a 0.3 index	reads a 0.4 index
new binary (fst 0.4)	yes	yes
old binary (fst 0.3)	yes	no — expected API version 2, got API version 3

So existing index files keep working, including the tryptic.fst and ninemer.fst published on the data server: those are read, never rewritten, by users. What does not work is going back — an index built after this change cannot be read by an older umgap. One-way migration, no action needed unless someone distributes a freshly built index to users on an older version.

Verification

• 38 tests pass, cargo +nightly fmt --check clean.
• pept2lca against a 0.3-built index returns correct taxa on both load paths (mmap and -m).
• buildindex -> printindex round-trips.
• Advisories in the resolved tree drop from 6 to 5; memmap is out of Cargo.lock entirely.

The remaining five (ansi_term, atty x2, proc-macro-error, structopt) all come from the clap 2 / structopt stack and go together with that upgrade.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.