Improve DAP user experience when `dockerfile` is a relative path

[rcjsuen]

buildx/docs/reference/buildx_dap_build.md

Lines 64 to 71 in 77315f9

	The following [launch request arguments](https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Launch) are supported. These are sent as a JSON body as part of the launch request.
	| Name | Type | Default | Description |
	|:--------------------|:--------------|:-------------|:-----------------------------------------------------------------------------|
	| `dockerfile` | `string` | `Dockerfile` | Name of the Dockerfile |
	| `contextPath` | `string` | `.` | Set the context path for the build (normally the first positional argument) |
	| `target` | `string` | | Set the target build stage to build |
	| `stopOnEntry` | `boolean` | `false` | Stop on the first instruction |

{
    "request": "launch",
    "contextPath": "/path/to/my/folder",
    "dockerfile": "Dockerfile"
}

The documentation says "Name of the Dockerfile" but it has to be an absolute path.

ERROR: failed to build: failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

I think we should return an error to the launch request if a non-absolute path was provided for dockerfile or allow it to go through and then opt to concatenate contextPath with dockerfile if it's non-absolute?

[jsternberg]

Investigating this a bit more, this seems to be dependent on where the DAP plugin invokes the command. Neovim seems to invoke it from the workspace root and the VSCode extension uses the workspace root explicitly (here).

I think we should add a note that the plugins should be invoked from the workspace root for consistency and the launch arguments are based on the equivalent arguments to buildx build.

[jsternberg]

I've opened #3432 to clarify the behavior we expect from official plugins.

[jsternberg]

Fixed by #3432.