Automated generation of builtin-mappings.yaml

This may warrant another tool (or something in this repo like cmd/dfc-util).

We should go out to Debian (and other OS repo sources), fetch OS-specific packages like .deb/.rpm/.apk, unpack them, and compare them to Chainguard/Wolfi packages using the apko solver.

The is an involved data/automation flow that may make sense to break into several subtasks:

• 1. Initial setup of dfc-util CLI skeleton
• 2. dfc-util os-snapshot --os=debian: A job to fetch and publish a snapshot of OS packages (Debian)
• 3. dfc-util os-snapshot --os=fedora: A job to fetch and publish a snapshot of OS packages (Fedora)
• 4. dfc-util os-snapshot --os=alpine: A job to fetch and publish a snapshot of OS packages (Alpine)
• 5. dfc-util builtin-mappings A job to regenerate the builtin-mappings.yaml file by comparing snapshots to Chainguard/Wolfi package indexes
• 6. The GitHub Actions workflows to run jobs described in 1-4 above and commit builtin-mappings.yaml back to the repo

Start by reviewing the existing cmd/dfc-util entry point and the current builtin-mappings.yaml file. Break the proposal into the listed os-snapshot, builtin-mappings, and GitHub Actions jobs, then identify how Debian, Fedora, Alpine, and Chainguard/Wolfi package data would be fetched and compared. Done means the agreed automation can regenerate builtin-mappings.yaml and publish the requested snapshots.