Closes: #227
Closes: #497

After hacking around with yara-x locally last night, the performance gains over Yara are definitely noticeable (usually 2x faster at minimum). Previous versions seemed to be slower (at least 0.10.0) but my earlier testing may have been bugged/flawed. That said, I wanted to get this rather large refactor up to test the CI experience again since we have to build the API from scratch, but when refreshing the sample data locally I was down to about ~24-25 seconds with the integration tests taking about 27 seconds (on my M1 Pro MBP).

The main limitation with yara-x is that it does not expose any functionality to turn off problematic rules. To handle this, I added functionality to remove rules prior to compilation so that they are not evaluated by the scanner.

To help with CPU overhead, the PR also adds a pool of scanners that can be re-used across files. Previously, we always GC'd the active scanner after each scan which had a sizable impact, especially for scan paths containing many files.

This PR also cleans up recursiveScan and fixes the behavior of longestUnique and splits out path-related functions into a new path.go file. Additionally, processArchive will now concurrently scan extracted files which was previous serial. With this change, I can scan the OpenJDK package which extracts roughly 136,000 files in ~70-90 seconds.

Outside of the longestUnique changes, the final, rendered output is essentially 1:1 with the current implementation.

Edit: this PR is about 3-4x faster in GHA with 8-core runners (even when running in a container):

go test -timeout 0 ./tests/...
ok  	github.com/chainguard-dev/malcontent/tests	49.979s

This is usually around ~170s.

The tests and golangci-lint jobs now run in a Wolfi container to avoid compiling the yara-x C API each time the Workflows run; this more than halves the runtime of each job (5+ minutes down to ~2 minutes).