CI/Dockerfiles: minor dockerfiles improvements

[dcaba]

• CI: suggesting to execute the PR test flow also on push events (useful while developing? At least it was for me)
• CI: executing a dumb docker-build for each Dockerfile to ensure we can generate images / there are no syntax issues or other base-image changes (we are pointing to latest!) that make break RUN statements.
• Dockerfiles: consolidating RUN stages to reduce the number of images
• Dockerfiles: cleaning apt cache after installing software, to save some space / make resulting image a bit slimmer, but..
• for the rust Dockerfile: caching the crates index to save time when building C@E apps (so bye bye disk savings)
• Dockerfiles: Consistent usage of curl --silent to avoid verbose docker-build output
• Dockerfiles: Removing bash-specific syntax that was generating errors in the output and probably breaking checksum validations
• Dockerfiles: Replacing adduser by useradd to avoid errors in the output (as adduser is expected to be interactive)

[Integralist]

Outside the concern of this PR but just thinking we should really have a Dockerfile-go as well.

[dcaba]

+1!! Our cli depends on the specific-programming-language build tooling, and I dont think that a common image bringing all languages tooling is going to scale well (will make the image even more huge). What we may want to do is to consolidate all Dockerfiles in a single one: a common stage can just install the fastly-cli, and then we can have dedicated stages per language we are supporting, each stage picking the common fastly-cli and adding the language-specific tooling (or inheriting it from the right base image). Then, rather than doing a docker-build against a specific Dockerfile, CI and users will need to be explicit on the stage we want to build (the common fastly-cli layers will be reused if you build more than one image/language, which is good for caching)

[Integralist]

@dcaba Nice. I bow to your knowledge in this area 🙇🏻 (ps, PRs welcome 😛)