Docker Build Cloud driver

[crazy-max]

This upstreams the Docker Build Cloud cloud driver into public Buildx so Build Cloud users can use the standard Buildx release path instead of a private client fork. The driver lets Buildx create builders from existing Build Cloud groups with --driver cloud <account>/<builder> or cloud://<account>/<builder>, resolves the managed BuildKit instances into Buildx nodes, authenticates with Docker credentials, and connects to the Build Cloud data plane while keeping the backend service implementation private.

The series adds the small builder and driver extension points needed for this integration, wires cloud pull through the upstream BuildKit session exporter path, preserves normal Buildx output behavior when cloud pull cannot be used, and documents the Build Cloud-specific create and output semantics. The Buildx reference links to the existing Docker Docs for Docker Build Cloud setup, Building with Docker Build Cloud, and Docker Build Cloud CI usage.

Special thanks, in no particular order, to @fiam, @jedevc, @silvin-lubecki, @sgarcez, @nicks, and @stevvooe for the work that made Docker Build Cloud possible. I may be missing people here, but the intent is to acknowledge the broader team effort behind this work.

[dvdksn]

I think we can defer some of this detail to a different doc. I'm opening a companion PR in docker/docs where I tried to cover cloud pull in a dedicated section in the exporter docs. We could cross-reference to that section from here and keep this high-level. Something like:

Suggested change

	Tagged builds without an explicit output, `--load`, and
	`--output type=docker` may use cloud pull to load the result into the selected
	Docker context. `default-load=false` does not disable cloud pull for tagged
	cloud builds with no explicit output. Explicit Docker archive, stdout, or
	directory destinations, such as `--output type=docker,dest=image.tar`, keep
	using normal Docker output handling.
	Cloud pull is only used for a single cloud-pullable output on a single node and
	single platform. Multi-node builds, multi-platform loads, conflicting Docker
	output contexts, and multiple distinct image output requests use the normal
	Buildx output path.
	When you don't specify an output, an untagged result remains in the cloud build
	cache. If you use `--tag`, Buildx automatically loads the image when the build
	targets a single platform and runs on one cloud node. For details about loading
	behavior, Docker contexts, and other output configurations, see
	[Load results from Docker Build Cloud](https://docs.docker.com/build/exporters/#load-results-from-docker-build-cloud).

[dvdksn]

The downstream docs PR is: docker/docs#25885

Here's the new section on cloud pull/loading results to the local store: https://deploy-preview-25885--docsdocker.netlify.app/build/exporters/#load-results-from-docker-build-cloud

(That might need some improvements still but it seems like a good place to cover it.)