replace `buildctl-daemonless.sh` with a dedicated command

Currently buildctl-daemonless.sh enables ephemeral builder use-cases, where buildkitd is spun up for just one build.
One of the example use-cases is to do with learning, arguably using this script is the easiest way to try buildkit. There are other use-cases, such as running builds in Kubernetes job or some other ephemeral mode of execution, where using long-running daemon is undesirable for some particular reason, e.g. when build chache has to be disable for all builds anyway.

Overall, the script does offer a way of solving the need for running buidkit in such a mode, however the scirpt uses shell to manage processes, which can be unreliable. Handling of daemon and client flags is also not very optimal from use-experience perspective, due to the level of inderection. The script also sends daemon logs to a file, which is challenging in some evironements. Of course, it's possible to add different environment variables to this script, but it will make the user experience more fragile.

More broadly, there is also a number of open issues to do with this scirpt.

It should be quite simple to create a dedicate command that combines daemon functionality with the client and doesn't need to rely on how process managedment in shell works, weather an init deamon is needed etc, instead it could just invoke Go functions (possibly via goroutines, and potentially still using the unix socket for comms). This will require moving code around, as cmd/buildkitd & cmd/buildctl are main packages and cannot be improted in another package, but it's also good practice to keep main package minimal and improt buiseness logic from another package, as it offers more flexibility for future refactoring and testing.

Review buildctl-daemonless.sh and the cmd/buildkitd and cmd/buildctl main packages first. Map the daemon and client responsibilities that must move out of the main packages, then define the dedicated command's interface and process handling. Done means ephemeral builds no longer depend on shell process management and the relevant daemon and client functionality remains usable.