Let dua-core queue more of the walk in place of the draining thread

[dduugg]

Summary

• dua-core 4.2.0 has Options::queued_batches_per_worker, from perf: let walk workers queue more batches ahead of the iterator Byron/dua-cli#413. pks now asks for room for 128 batches per worker, and the thread that Walk the app with dua-core in place of jwalk #79 added to drain the walk is gone.
• With dua-core's default of 2, the workers stop each time the walk's loop parses a package.yml. The thread kept them going by draining the walk into an unbounded channel.
• 4.2.0 also fixes how relative paths are resolved on Windows when they're verbatim paths.

Measurements

The walk loop's median wait on dua-core over 15 runs in a large Rails app, at a load average of about 22 on 12 cores:

Setup	Waiting on the walk
dua-core's default of 2 per worker	301 ms
The draining thread (main)	113 ms
32 per worker	100 ms
128 per worker	64 ms
512 per worker	60 ms

The total walk time was too noisy to separate the setups, apart from the default of 2. Rerun with 4.2.0 at a load average of about 47, it's a median 801 ms against 820 ms for main.

Test plan

• cargo test (374 tests), cargo fmt --check and cargo clippy --all-targets --all-features -- -Dwarnings.
• list-included-files, list-packs and list-references match main on every fixture and four Rails apps. list-references on app_with_monkey_patches panics on both, naming either duplicate constant at random, as on main.
• CI's Build jobs, including Windows.