build: don't hardcode classic builder for windows daemons

[thaJeztah]

Description

relates to:

• Set buildx as default builder #3314
• api: set default "Builder-Version" to "2" (BuildKit) on Linux moby/moby#43657
• https://techcommunity.microsoft.com/t5/containers/experimental-windows-containers-support-for-buildkit-released-in/ba-p/4096116

When support for BuildKit was removed from the CLI (using Buildx instead), we implemented logic to detect whether BuildKit or the classic builder should be used. As Windows did not support BuildKit, the CLI was hard-coded to use the classic builder in Windows binaries (with an option to force using buildx when using docker buildx install).

While current versions of the Docker Engine do not yet support BuildKit on Windows, work is in progress to add support for it, and BuildKit 0.13 has experimental support for Windows.

The daemon provides a BuilderVersion field as part of the /_ping response to advertise the suggested version of the Builder to use. Currently that is 2 (BuildKit) on Linux, and 1 (classic builder) on Windows;

curl -I --unix-socket /var/run/docker.sock http://localhost/_ping
HTTP/1.1 200 OK
Api-Version: 1.45
Builder-Version: 2
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: text/plain; charset=utf-8
Date: Wed, 10 Apr 2024 09:11:20 GMT
Docker-Experimental: false
Ostype: linux
Pragma: no-cache
Server: Docker/26.0.0 (linux)
Swarm: active/manager

While that information must be considered a recommendation (the client is still allowed to opt-in/opt-out), we should use this information as part of the logic in the CLI to decide whether BuildKit or the legacy builder should be used, so that the CLI can be used with a Windows daemon that has experimental support for BuildKit enabled would automatically use BuildKit without changes in the CLI's configuration.

Note that, for this to be functional, a Windows Buildx binary (CLI-plugin) must be present; similar to how this is needed on Linux.

[thaJeztah]

Just adding here, as I'm not sure now if it was hard-coded for Windows CLI or if the CLI is connected to a Windows daemon (in either case, the logic should look at what the daemon supports, and not based on platform)