Parallelize discover_paths

[divergentdave]

Depends on #4. Most of the loops can be rewritten to use rayon ParallelIterator interfaces, but I'll need connection pools first, because rusqlite::Connection is Send but not Sync.

[divergentdave]

DataFileSet is not compatible with this idea, as it holds a single open file handle for each .dat file.

[divergentdave]

It may make more sense to do fine-grained parallelization within decompress_file() (with a long-lived threadpool). The file format is set up to encourage this, seeing as the blocks can be decompressed independently. We could even pre-allocate one Vec<u8> and decompress into it, by doing some length math and splitting up mutable splices first.

Separately, we could parallelize the other downstream parts of discover_paths(), by fanning out after one coordinator thread does file decompression. This both solves the exclusive access problem, and keeps parallelism from ruining our disk locality. For the regex pass, we could have the main file decompression thread feeding a channel with a small fixed buffer (so that the working set doesn't blow up, but downstream threads will still have something to work on while a large file is being decompressed). Then, other threads could consume decompressed files from the channel, scan them (which will be CPU-expensive), and touch the database. For the rest of the passes, which all depend on root.exl, we can read the file up front, split work among threads, and then the worker threads can check indexes and the database without issue.