buildbox: build images from the provisioning manifest source of truth (Dockerfile / BuildKit / Packer)

[darkn3rd]

Currently the provisioning manifests (scriptbox/config/*.yml) only drive in-place provisioning of a running VM (bash/PowerShell installers via generate_install_script.rb, and now a Chef data bag via generate_chef_databag.rb). There's no path from the same source of truth to an actual built image/artifact - this was deposited as a speculative idea in #27, not yet scoped as real work.

Idea: a new buildbox area (separate from configbox, per #27) that reuses the existing manifest compiler pipeline (flatten/resolve!/dedup! in resolve_order.rb) the same way generate_chef_databag.rb does, but emits build recipes instead of a data bag - Dockerfile, BuildKit, and Packer - so the same manifest that installs zsh+golang-go+dotnet-sdk-10.0 etc. into a live VM can also produce a container image or a machine image with the same package set.

• Dockerfile path: a generate_dockerfile.rb emitting a RUN per resolved step (or consolidated per-area RUN groups, mirroring generate_chef_databag.rb's own consolidate_apt)
• BuildKit path: evaluate whether this is just "Dockerfile + docker buildx build" (BuildKit is Docker's default builder already) vs. a real LLB-graph generator - likely the former unless there's a concrete reason to hand-build the LLB graph
• Packer path: a generate_packer_template.rb (.pkr.hcl emission) using shell/file provisioner blocks, reusing the bash installer output from generate_install_script.rb rather than re-deriving package commands a third way
• Decide manifest scope - full platform tree vs. a specific area (e.g. just compiled_lang) - likely wants Source of truth: tag package entries for --select/--exclude filtering #16's --select/--exclude filtering so a build only includes what an image actually needs
• file:/append:/apt_repository: steps need Dockerfile/Packer equivalents too (COPY/heredoc RUN, RUN echo >>, RUN add-apt-repository)
• Registry push is out of scope for the initial pass - per configbox: future enhancements - buildbox (packer/docker/podman) and consul-template dynamic config #27, that's "meaningfully more infrastructure than the rest of configbox needs"; start with local docker build/packer build output only
• Base image(s) per platform manifest (ubuntu2204.yml -> ubuntu:22.04?) not defined anywhere yet

Related: #27 (where this was first deposited), #17 (same "derive from the source of truth" pattern, for CM tools), #16 (tag filtering, useful for scoping a build).