Use --platform when we build invocation images and document what we support

[carolynvs]

In a world before M1 and IOT, we decided that we would just have bundles create a single platform/arch invocation image (linux/amd64) and it's been working well. Now that a lot of the Porter devs are building on M1, we need to figure out how Porter should build the bundle's image, and if it should be:

1. Fixed as amd64
2. Multi-arch amd64/arm64 (not sure how well we've really planned that out in the CNAB spec but I think it should work since we use buildx under the covers)
3. YOLO (this is what we do today), whatever platform you are on, that's what we build.

The YOLO option isn't acceptable because if I publish a bundle from my M1, someone on linux arm64 can't run it. Docker Desktop kind of hides that this is a problem and does unknown magic to make running the other arch work but we need something that once distributed works for most people.

Updated: For 1.0 if we can do multi-arch without a TON of work, let's do that. Otherwise let's fix the platform for the invocation image to linux/amd64 and then document which architecture works with bundles. Then in a point release after v1.0 we can add multi-arch support. The big question is: what is the default, and how does someone opt-in/out of multi-arch images.

[carolynvs]

Yingrong and I spoke and we are going to make porter consistent by always specifying the platform for now. Later if we want to support other architectures, we should do a formal design and not just let this bug act as a inconsistent workaround.

[carolynvs]

Update the dockerfile template to specify the platform:

FROM --platform linux/amd64 debian:slim

Then document what we support and that you can use a custom dockerfile to change the platform.

All the rest of the stuff discussed in this issue should be split into a new PEP. I've updated the title to reflect what we want to do.

[github-actions]

Closed by #2286.