feat(generator): add per-process scraper to hostmetrics

[chelseawright7]

Proposed Change

Split out of #294 per review — that PR is now journald data library only, and this one carries the scraper on its own.

The existing processes scraper reports host-wide counts (system.processes.count) only, so nothing in Blitz emitted per-process telemetry. The new process scraper emits:

Metric	Type	Unit
process.memory.usage	gauge	By
process.memory.virtual	gauge	By
process.cpu.time	sum, by state	s
process.disk.io	sum, by direction	By
process.threads	gauge	{thread}
process.open_file_descriptors	gauge	{count}

Each record carries its own resource map with the process identity — process.pid, process.parent_pid, process.executable.name, process.executable.path, process.command, process.command_line, process.command_args, process.owner, and on Linux process.cgroup. That resource-level identity is what makes process metrics high cardinality, and therefore what reduction and normalization processors act on; putting it in datapoint attributes instead would not exercise the same downstream code paths.

The simulated process table varies by generator.hostmetrics.os (Linux daemons vs Windows services), and always contains daemons under 1 MiB resident so memory-threshold filters have something to drop.

Checklist

• Changes are tested
• CI has passed

go build ./..., go test ./..., make lint and make security (178 files, 0 issues) all pass.

New unit tests in generator/hostmetrics/process_test.go cover: resource-attribute placement, that the shared base resource map is never mutated by a scrape, that each template gets a distinct resource map, that a scrape yields processes both under and over 1 MiB resident, Windows-specific behavior (.exe names, no cgroup), and command-line assembly with and without args. Existing scraper-count assertions updated 8 → 9.

Smoke-tested through the CLI:

blitz --generator-type hostmetrics --generator-hostmetrics-scrapers process \
      --output-type stdout --generator-count 4