Allow more parallelism than rayon default (thread per core)

Ripunzip uses rayon default thread pool, which I believe is one thread per logical core.

This is appropriate for cpu-bound work. However, unzipping spends a lot of time blocking on I/O, waiting for disk or network.

In such cases, you benefit from more threads than cores, so you can issue more iops in parallel. Particularly with SSDs that require many parallel I/O requests to saturate the hardware.

Ripgrep could either:
- provide a tuning argument like -j
- or auto tune the thread pool size (somehow)
- or both

Start by locating where ripunzip initializes Rayon’s default thread pool and where command-line options are defined. Compare the proposed -j tuning argument with automatic sizing for I/O-bound extraction, then establish how the chosen behavior should be evaluated on disk or network workloads.

Written by the indexing model from the issue text.