feat: MultiArch phase 2 pack buildpack package implementation ideas

[WYGIN]

you can keep track of my phase 2 here (WIP), based on multi-arch-builders-and-packages RFC and and @jjbustamante POC.
The approch i am willing to is mostly same as juan's pr and with minimal changes.
currently for pack buildpack package the pack will work as below:

1. no more the pack buildpack package <name> name will have no effect, instead the < name><-os><-arch><-variant><-distroName><@distroVersion>.cnb (also the id and version columns from buildpack.toml file will generate similar filename) format will symlink the image-digest.cnb
2. when pack building buildpack it will check targets table in buildpack.toml and creates a multi-arch imageindex everytime, no matter if the targets are defined or not (even if the user is not creating mutli-arch image with, i mean even if buildpack authors don't organizes the binaries according to their os/arch with a structure). If target is not defined, a single manifest will be added, else multiple manifests(one for each target)
3. I am thinking of not adding targets to package.toml as we can add targets in buildpack.toml and confirm it as composite buildpack by parsing orders table. let me know if there is any other reason behind adding targets to package.toml
4. for multi arch images the pack will loop over each target and creates a package.toml and buildpack.toml files in platform root folder
5. the package.toml and buildpack.toml files in platform root folder will have all the columns ( like dependencies.uri in package.toml, order.id in buildpack.toml ) will refer platform specific values. and we will use platform root folder's (the newly created package.toml and buildpack.toml files) Config files to build platform specific images.

# **package.toml** in root folder

[buildpack]
uri = "docker://examples/my-multiarch-buildpack" # not sure if `docker://` will also point an image in registry, assuming that `docker://` will only refer a local docker image that will be loaded using `local.NewImage(...)`
# OR a .tgz with the previous folder structure
uri = "my-multiarch-buildpack.tgz"
# OR a registry image
uri = "examples/my-multiarch-buildpack:latest"
# OR a image(deprecated) i am not sure what is the format of image assuming it as below
image = "my-multiarch-buildpack"

will be converted into

# package.toml in platform root directory

[buildpack]
uri = "docker://examples/my-multiarch-buildpack-<os>-<arch>-<variant>-<distroName>@<distroVersion>"
# OR a .tgz with the previous folder structure
uri = "my-multiarch-buildpack-<os>-<arch>-<variant>-<distroName>@<distroVersion>.tgz"
# OR a registry image
uri = "examples/my-multiarch-buildpack@sha256:<target-specific-digest>"
# OR a image(deprecated) i am not sure what is the format of image assuming it as below
image = "my-multiarch-buildpack-<os>-<arch>-<variant>-<distroName>@<distroVersion>"

and a buildpack.toml file for composite images

# buildpack.toml in root directory

[[order]]
[[order.group]]
id = "<some order>"
version = "<some version>"

converted into

[[order]]
[[order.group]]
id = "<some order>-<os>-<arch>-<variant>-<distroName>@<distroVersion>" # if it is a registry then a platform specific digest
version = "<some version>" # version has no effect

6. we call image setters ( image.SetOS , image.SetArchitecture , image.SetVariant , image.SetOSVersion , image.SetFeatures , image.SetOSFeatures , image.SetURLs , image.SetAnnotations ) right after we create an image and right before we Save (or) push image
7. A new table called specs will be added in [[targets.distributions]] table of [[targets]] table which has target specific fields including defining v1.Platform fields along with Flatten , FlattenExclude , Labels to give more control over each image when building multi arch images

well thats it pack buildpack package , looking for your feedback to improve it.

cc: @natalieparellano @jericop @jjbustamante