Add opt-in SessionOptions::trust_fastresume to skip the startup rechecka

[ikaradimas]

Problem

With fastresume: true, librqbit still re-verifies every restored torrent on
every session start. TorrentStateInitializing::validate_fastresume loads the
persisted piece bitfield and then, even when it is present and the correct
length, SHA-1-validates a sample of pieces: at least one piece per file,
plus a ~2% random sample of the rest.

For a large library of many-file torrents (music discographies, season packs
with hundreds of files each) the "≥1 piece per file" minimum alone forces
thousands of piece reads on every launch. On one user's Windows session this
was ~410s to restore 26 torrents (22 complete and seeding), re-hashing data
it already had a valid bitfield for. Since Session::new_with_opts doesn't
return until every torrent is added and the checks contend for the disk, the
client is unusable until it finishes.

There's no way to opt out today: paused still checks, list_only skips
adding the torrent, and concurrent_init_limit only changes parallelism.

Change

Add an opt-in SessionOptions::trust_fastresume (default false, so existing
behavior is unchanged). When it is set and validate_fastresume loads a
bitfield whose length matches piece_bitfield_bytes(), it trusts the bitfield
and returns immediately, skipping the sampling loop.

Safety is preserved for the risky cases:

• a previously-errored torrent still has its bitfield cleared and gets a
  full recheck (have_pieces is None before validate_fastresume);
• a missing or wrong-length bitfield still falls through to the full
  initial_check;
• on-disk corruption is still caught at the per-piece level while
  seeding/downloading.

This matches clients like qBittorrent/Transmission, which trust fast-resume
data on start and recheck only on explicit request.

Testing

Ran against a real session of complete torrents with trust_fastresume: true:
the trust branch is taken for every restored torrent and initial_check
("Doing initial checksum validation…") never runs. With the flag false
(default), behavior is unchanged.

[ikatson]

I get the pain - fastresume still checks too much, I need to replace that algorithm, it's too slow. But regardless, my idea is to still do some sanity checks, we just need to do fewer of them.

Do you think this change will still be needed if we do say 64 reads per torrent (instead of a potentially larger number today)?

[ikatson]

#632 - related