[Request]: Support custom BuildKit frontends

### Feature or enhancement request details

# Background

BuildKit is frontend-agnostic and lets you point at any LLB-speaking frontend via the `# syntax=...` directive (or by configuring the frontend explicitly). A good example is the frontend I've built called [`Yamlfile`](https://builderhub.github.io/Yamlfile/).

## Current Behavior

Right now the shim has Dockerfile-specific logic that gets in the way. This results in `container build` effectively being [locked to Dockerfile](https://github.com/apple/container-builder-shim/blob/fbb4645242edbf2707df3a8ce2fb77a7b9bab6a1/pkg/build/build.go#L174) even though the underlying BuildKit instance could run other frontends without issue.

If I try to build something with a custom frontend (Yamlfile for example), I receive the following error:

```
Error: unknown: "dockerfile parse error on line 2: unknown instruction: apiVersion:"
```

## Extended Behavior

It would be useful if the shim stayed out of the way on the build-definition side and just did the protocol translation + file serving generically.

This would let people use any BuildKit frontend, like Yamlfile `container build -f Yamlfile`:

```yaml
# syntax=ghcr.io/builderhub/yamlfile:latest
apiVersion: v1alpha1
targets:
hello:
from: alpine
steps:
- run:
command: echo "hello from Yamlfile" > /msg.txt
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start at pkg/build/build.go around line 174 and reproduce the Yamlfile example with `container build -f Yamlfile`. Trace which Dockerfile-specific parsing and file-serving paths are involved, then verify that a custom BuildKit frontend can receive its build definition without Dockerfile parsing and that the example builds successfully.

Written by the indexing model from the issue text.