enhancement: catalog Go dependencies from compiled binary build info

Tracked by #247.

## Summary

Installed language artifacts cover Python and Node only. Go is the gap with a real hole behind it: a distroless Go image has no package database and no metadata files, so a scan finds nothing and errors, even though the binary itself records every module it was built from.

## Current state

- `src/filesystem/artifacts/` holds `python.rs` and `node.rs`, registered as the only two catalogers, [src/filesystem/artifacts/mod.rs#L62-L72](https://github.com/anistark/feluda/blob/83b4051/src/filesystem/artifacts/mod.rs#L62-L72).
- Ruby gemspecs, jar manifests and Go build info are named as tracked separately, [src/filesystem/artifacts/mod.rs#L11](https://github.com/anistark/feluda/blob/83b4051/src/filesystem/artifacts/mod.rs#L11), and separately turned out to mean nowhere.
- `Ecosystem::Golang` already exists, [src/purl.rs#L28](https://github.com/anistark/feluda/blob/83b4051/src/purl.rs#L28), so findings have somewhere to land.

## Design decisions

Every cataloger so far recognises a metadata file and reads it, [`Cataloger`](https://github.com/anistark/feluda/blob/83b4051/src/filesystem/artifacts/mod.rs#L54-L59). Build info lives in a section of an executable, so this is the first cataloger that parses a container format rather than a file, and it needs ELF, Mach-O and PE handling to cover what people actually ship. That is the decision this issue asks for: whether reading compiled binaries is in scope for `src/filesystem`.

Gemspecs and jars raise smaller versions of the same question and are deliberately out of scope here. Jars mean opening archives for `pom.properties` and `MANIFEST.MF`. Gemspecs are plain files but are Ruby DSL rather than data, so the question there is how much to match rather than evaluate.

## Proposed change

- Add a Go cataloger that recognises executables and reads the `go:buildinfo` blob, yielding module path and version per dependency.
- Resolve licenses through the existing pkg.go.dev path, since build info carries no license string.
- Skip binaries with no build info rather than reporting them.

## Acceptance criteria

- `feluda --filesystem ` reports the modules compiled into the binary instead of finding nothing.
- Modules already owned by an OS package are deduped the way Python and Node artifacts are.
- Scanning a large tree of non-Go binaries does not measurably slow the walk.

## References

- `debug/buildinfo`, https://pkg.go.dev/debug/buildinfo