Buildx imagetools create should allow reading content from `oci-layout://` directories

[jedevc]

Description

Would resolve #1152.

Essentially, it's becoming more common for users to want to export their images, and then push them later. There's a few legitimate reasons to want to do this:

• Import the image into docker, and run validation tests on it before pushing
• Manually verify image attestations like SBOMs, Provenance before pushing
• Split out the build and push sections of a push to allow more manual control over flaky registries

So a workflow something like:

$ docker buildx build -t myorg/myimage --push .

Could be broken down into:

$ docker buildx build --output type=oci,dest=./my-image,tar=false
...
$ docker buildx imagetools create -t myorg/myimage oci-layout://my-image

The reason for using the oci-layout URL schema is just since BuildKit already uses this for overriding named contexts, so it would be good to stick with that.

If we choose to go that way, we should probably also support the docker-image:// schema (the default, for consistency) from https://github.com/moby/buildkit/blob/23d38a7220bff812b8a1de07c1f02b4e46cacd7c/frontend/dockerui/namedcontext.go#L40. Supporting any of the other schemas is probably not a great idea, since 1. it doesn't make a huge amount of sense, and 2. we can't really reuse any of the frontend side code for this anyways.

[Oliniusz]

Another reason for the separation is that I would like to run those steps in parallel:

• terraform apply that also creates the ECR repository,
• in the meantime I want to start the docker build.

When the terraform apply has finished I can push the image to the newly created repository.

[crazy-max]

Done in v0.33.0 (#3721): oci-layout://path[:tag|@digest] works as source and target for imagetools create and for inspect, and can be mixed with registry references. The reference pages still need a docs follow-up for it.