Adopt KRM for `apko` file format

[maintainer mattmoor]: _(this got a little rambly, but hopefully it makes sense)_ I don't see them as mutually exclusive TBH. Given that JSON is valid yaml, there's nothing stopping the use of `kyaml` transformers prior to `apko_config`'s `config_contents` or even between `apko_config` and `apko_build`. I would say the most interesting manipulation of the config (`apko_config`) is the production of a "locked" file form which is a task that has a level of semantic depth beyond what something like kustomize or kpt could do, since it requires a fairly deep semantic understanding. `apko show-packages` can be used to get a similar package list directly from `apko` FWIW. That said, in my mind the main feature of terraform isn't the templating, it is enabling an orchestrated composition of tools, e.g. describing how we take an `apko` SBOM and attest it with `cosign`, or tag the resulting digest based on package versions, ...

Context: Issue chainguard-dev/apko#725 (closed, 10 comments): Once you have your image configs and build scripts setup, the majority of the work involved in operating a [secure software factory](https://www.chainguard.dev/unchained/secure-your-software-factory-with-melange-and-apko) is config management. Kubernetes ecosystem has great config management tooling and libraries, which comes as no surprise given that the [Kubernetes Resource Model (KRM)](https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/resource-management.md#declarative-configuration) was designed with that intent. Virtually all manipulation that needs to ta