Feature: Allow docker build to stop processes with signal

When a docker build is cancelled (either with CTRL+C or by the client losing connection to the daemon), allow the use of a SIGTERM (or other signal) to stop the running processes in the build container -- similar to how docker run does by default. This behavior does not need to be made default, but can be implemented as an option (which should also be settable from a docker-compose.yaml).

My use case is when my Dockerfile uses BuildKit cache mounts. With the current abrupt-kill method, the cache mount ends up having partially-written build products (e.g. C++ object files) with new timestamps, so make-based build systems encounter problems on the next attempt. If this feature is implemented, then GNU Make's .DELETE_ON_ERROR can respond to the signal by deleting the partially-written build products, so that next time that build step is repeated.

While this problem can happen when manual docker build runs are cancelled by the user, it is more problematic when it happens when docker-compose build --parallel (which is the default in Docker Compose V2) encounters any spurious problem in one of the image builds (e.g. timeout when downloading packages) and cancels the other image builds abruptly. (My current workaround is to disable Docker Compose V2.)

Start by tracing cancellation in the docker build entry point and compare it with how docker run stops processes. Check how docker-compose build --parallel propagates cancellation and how BuildKit cache mounts are handled. Done means an opt-in signal can stop build processes gracefully and the option is available through docker-compose.yaml.