Reduce memory accumulation for long-running scans

[egibs]

This PR is a targeted attempt at mitigating an edge-case where long-running scans of millions of files will eventually OOM a system if only the top-level directory is provided as a scan path.

This isn't an all-encompassing or holistic fix but helps quite a bit and there are still improvements such as streaming paths/results which we can make if this is not sufficient.

The main improvements are the usage of channels/pinning instead of a sync.Pool for the scanners which are relatively volatile (at high levels of concurrency, the sync.Pool GC would make them panic, for instance) along with leveraging file descriptors for scanning files. go-yara supported this natively, but we have to get a bit creative with yara-x if we want to avoid reading every single file into memory via io.ReadAll or the current implementation. The downside is that we still need the file's contents to calculate its hash and pull out the match strings. If necessary, these can be optimized in a future PR.

I ran several scans of ~14 million files each on a VM with 512GB of RAM and did not OOM or panic once, though I did cap out at about ~410GB of memory usage. If all else fails, we can drop the scanner pool and run single-use scanners via yrs.Scan which is much slower because of the scanner creation/destruction overhead but also has relatively little memory impact.

[eslerm]

VM with 512GB of RAM and did not OOM or panic once

🤯