Consider exec form ENTRYPOINT for Dockerfile

The grate Dockerfile uses the shell form of ENTRYPOINT:

https://github.com/grate-devs/grate/blob/6226b28d22f962ab8ca264575b124a04ea7fadf7/installers/docker/Dockerfile#L25

[The shell form of `ENTRYPOINT` ignores any `CMD` or `docker run` command line arguments](https://docs.docker.com/reference/dockerfile/#:~:text=The%20shell%20form%20of%20ENTRYPOINT%20ignores%20any%20CMD%20or%20docker%20run%20command%20line%20arguments.), which means that users running grate via Docker can't easily add extra command line flags to the ones that are executed by default. By contrast, [Command line arguments to `docker run ` will be appended after all elements in an exec form `ENTRYPOINT`](https://docs.docker.com/reference/dockerfile/#:~:text=Command%20line%20arguments%20to%20docker%20run%20%3Cimage%3E%20will%20be%20appended%20after%20all%20elements%20in%20an%20exec%20form%20ENTRYPOINT). As a result, switching to the exec form of ENTRYPOINT would enable users to concisely add additional flags to the normal command, with all of its arguments and reading of env vars.

As a motivating example, it would allow easily adding `--warnandignoreononetimescriptchanges` to enable editing already-run migrations that are under development, without the user needing to manually delete rows from the grate.ScriptsRun table.

P.S. Thanks for grate!

Inspect installers/docker/Dockerfile at the ENTRYPOINT on line 25, then compare its current behavior with Docker's shell and exec forms. Verify the change by running the image with an additional command-line flag, including the motivating migration flag, and confirm that the default arguments and environment-variable handling still work.

Written by the indexing model from the issue text.