Fix attestation overrides with duplicate types

[jedevc]

Fixes the following issue described by @crazy-max:

For this command:

/usr/bin/docker buildx bake --set *.output=type=image,name=localhost:5000/name/app:latest,push=true --set *.cache-from=type=gha,scope=attests-image --set *.cache-to=type=gha,scope=attests-image,mode=max --metadata-file /tmp/docker-actions-toolkit-N7ECkf/metadata-file --provenance mode=max,builder-id=https://github.com/docker/bake-action/actions/runs/4540267123 --sbom true image --print

I have the --sbom true flag and also type=sbom in my bake definition so error looks good. But I wonder if --provenance or --sbom for bake cmd should just overwrite the one defined in the definition instead of checking for dup?
I say that because, e.g. --sbom is shorthand for --set=*.attest=type=sbom, which is an override and imo should just override 😄 We have the same for --push which override the output field atm. I think that makes sense.

Essentially, we could not specify --sbom=<bool> as a flag if type=sbom was set on an individual bake target, even though the expected behavior is that the command line should override this. This behavior was introduced in #1475.

This PR adds a collection of test cases to ensure correct behavior when the magic internal value disabled is set (which is what is configured when the --sbom flag is used), as well as fixing the underlying cause.

The fix is fairly simple - we can allow merging duplicate types for the attestation key iff disabled is set on that attestation field. This isn't quite the same as reverting #1475, since the values are correctly merged if the user provides duplicate flags.

[tonistiigi]

I don't really understand how these make sense. If the user sets that sbom should be disabled then why don't we just set it like that.

I think --set should either replace the attestation with the same type or append the non-type keys. Adding a second record doesn't make sense to me. If that sounds too magical then we can replace the whole block.

[jedevc]

Have tidied this up now (apologies for the delay).

A better fix is just to "replace the attestation with the same type", with the later attestations overriding the former ones. We still need some additional logic for the build command to ensure that the pattern from #1475 doesn't cause confusion (some more details in the commit message).

[tonistiigi]

Why are we doing this in the buildopt level? This means that --print will show one set of values, but what actually gets built is different.

[jedevc]

🤦 done another time, this time doing so at the bake level, so should preserve with --print.