Remove scanner pool in favor of single-use scanners

[egibs]

The scanner pool concept was neat in theory, but yara-x leverages WASM which exhibits unpredictable behavior when a new scanner is created. Notably, each new scanner is allocated 8GB of virtual memory for the time being and this value is not configurable. Controlling this behavior with a separate value then adds another layer of complexity.

This PR reverts to the original pattern we used for go-yara with the main downside being that we are unable to scan file descriptors with yara-x and must instead read the entire file into memory before scanning it. That said, we'll be able to directly influence how many scanners are created with c.Concurrency rather than needing to account for two values. Ultimately, not using the scanner pool has little impact on performance (though I'd much rather have stability right now anyway).

To allow for yara-x to work in environments like Cloud Run, we'll still need a change that allows for WASM tuning to drop the memory reservation to hopefully free up virtual memory overhead and prevent panics.

[stevebeattie]

malcontent/cmd/mal/mal.go

Lines 372 to 376 in d343832

	&cli.IntFlag{
	Name: "scanners",
	Value: runtime.NumCPU(),
	Usage: "Number of scanners to create",
	Destination: &scannersFlag,

Do want to mark this flag as currently not being honored?

[egibs]

malcontent/cmd/mal/mal.go

Lines 372 to 376 in d343832

	&cli.IntFlag{
	Name: "scanners",
	Value: runtime.NumCPU(),
	Usage: "Number of scanners to create",
	Destination: &scannersFlag,

Do want to mark this flag as currently not being honored?

Oh, I need to remove that too.

I'm working on a Wolfi PR to help with our reservation problem as in parallel to this.