Add archive support (Unpackerr integration): fix silent no-op on archive-only transfers, opt-in RAR downloading

[msmarcal]

TL;DR

Transfers containing only archive files (multi-volume RAR releases, common on
many indexers) are currently marked as imported and deleted without a single
byte ever being downloaded. This PR fixes that silent failure and, behind a
new opt-in flag, turns putioarr + Unpackerr
into a fully working extraction pipeline - the same setup people already run
with qBittorrent/SABnzbd, now working with put.io.

The bug (affects everyone, no config change needed to hit it)

put.io classifies .rar/.rNN parts as ARCHIVE. In
recurse_download_targets(), only VIDEO and AUDIO produce download
targets, so an archive-only transfer yields zero File targets. Then in
is_imported():

results.into_iter().all(|x| x)   // .all() on an EMPTY vec == true

Vacuous truth: with no targets, the transfer is instantly considered
"imported". The observable sequence, taken from real logs, is:

17:45:27Z directory created
17:45:27Z download done
17:45:27Z imported
17:45:27Z deleted

Same second, zero bytes downloaded, transfer gone. From the user's side the
*arr shows a download that "completed" and then nothing ever arrives - one of
those issues that is very hard to diagnose and easy to blame on the *arr or
on put.io itself.

What this PR does

1. Fixes the vacuous-truth bug: transfers no longer complete on an empty
   target list.
2. New config flag download_archives (default: false): when enabled,
   ARCHIVE files become regular download targets and are fetched to disk,
   where an external extractor (Unpackerr) picks them up. With the flag off,
   behavior is byte-for-byte identical to today - existing setups are
   untouched.
3. Archive-aware import detection in is_imported(). The *arr never
   imports the .rar parts themselves, it imports the video Unpackerr
   extracts next to them. So archive targets are considered imported when
   either:
   • the part no longer exists on disk (extractor configured with
     delete_orig), or
   • the *arr history contains a downloadFolderImported event whose
     droppedPath lives inside the transfer's folder. Matching is done on
     the folder name, not the full path, so it works even when putioarr
     and the *arr see the download directory under different path mappings
     (Docker setups).
4. One history lookup per transfer, not per part: a 71-part RAR triggers
   a single cached directory check instead of 71 history scans.
5. README updated with the new config option and a dedicated "Archive /
   RAR support" section.

Tested end-to-end on a real deployment

Validated in production (Radarr + Unpackerr + putioarr in Docker) with a real
71-part, 6.6 GB RAR release:

step	result
putioarr downloads all 71 parts	first time archive parts ever reach disk
download done -> watching imports	waits instead of deleting instantly
Unpackerr extracts the mkv (2m45s)	extraction works, no race condition
Radarr imports the extracted file	downloadFolderImported in history
putioarr detects it -> watching seeding	remote cleanup proceeds as usual

Also verified that with download_archives = false (default) the behavior is
unchanged, and cargo check is clean.

Why this belongs upstream

Multi-volume RAR releases are unavoidable on several trackers, and right now
putioarr users have to reject them via custom formats (losing otherwise-best
releases) or lose downloads silently. Unpackerr is the de-facto standard
companion for every other download client in the *arr ecosystem; this PR is
the missing piece that makes putioarr a first-class citizen of that stack,
without changing anything for users who do not need it.

Happy to adjust naming, split commits differently, or add docs/README notes
as you prefer.