Improve error message when there's a conflict between `pull_policy` and `allowed_pull_policies` settings

What does this MR do?

This MR adds the pull_policy configuration source (.gitlab-ci.yaml, config.toml, or a default) to the error shown when there is a conflict between the pull_policy and allowed_pull_policies. It also adds to the error message the name of the image being pulled. The error messages now read like so:

"failed to pull image 'alpine': conflict in allowed_pull_policies ([if-not-present]) and pull_policy ([always]) configured by/in config.toml "
"failed to pull image 'alpine': conflict in allowed_pull_policies ([if-not-present]) and pull_policy ([always]) configured by/in gitlab-ci.yaml "
"failed to pull image 'alpine': conflict in allowed_pull_policies ([if-not-present]) and pull_policy ([always]) configured by/in default"

Why was this MR needed?

#29115 (closed) asks for the error message shown when there is a conflict between the pull_policy and allowed_pull_policies to specify the source of the offending configuration (i.e. in which file the offending configuration is made). allowed_pull_policies can only be configured in the runner's config.toml (for now?), but pull_policy can be configured either in the project's .gitlab-ci.yaml or the runner's config.toml, OR a default value will take effect if it was not configured. Knowing this will make it easier for users to debug/fix pipeline errors related to pulling docker images.

I've also augmented the error with the image name because this configuration conflict can also affect gitlab helper images (e.g. registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper), which ONLY use the pull_policy from confg.toml. Not mentioning the image in the final error could lead to all manner of confusion, like "why isn't the pull_policy in gitlab-ci being propagated to the runner?" Including the image name in the error message will hopefully avoid that.

What's the best way to test this MR?

1. register a runner with a docker or kubernetes executor
2. configure the project's pull_policy (i.e. gitlab-ci) and the runner's allowed_pull_policies (i.e. config.tml) in an incompatible way
3. trigger a pipeline run
4. watch the runner's logs to see the expected error message, OR just wait for the job to fail and the failure to appear on the pipeline run report. in this case the error should mention that the pull_policy configuration was made in the project's .gitlab-ci.yaml.

Repeat 2-4 but with the following gonfigurations:

• pull_policy configured in both the project and runner -> error message should mention project config file
• pull_policy configured in runner only -> error message should mention runner config file
• pull_policy not configured anywhere -> error message should mention default

What are the relevant issue numbers?

• #29115 (closed)

Notes:

• This MR is best reviewed commit at a time; it'll be much easier to digest read that way.
• This MR is built atop !3504 (merged) since the latter contains changes that touch the same bits of code that this MR does, and merge conflicts will result when the latter is merged and the former rebased. Once !3504 (merged) is merged, I'll rebase this branch. So, DO NOT review the commits in !3504 (merged). Start at [docker] Changes made automatically by gopls. !3504 (merged) has been merged and this branch/MR rebased against main.
• This MR only addresses #29115 (closed) for the docker executor. Analogous changes will be required for the kubernetes executor. I can/will make those changes is this same MR, or in a new one, but I though I'd at least get a review on the work so far in case it's going in the wrong direction. kubernetes executor handling added.