automatic release detection does not allow for local overrides

since we have automatic release detection, which pulls in images based on the release found in d/changelog. afaict this works well for simple cases, but breaks for more complicated pipelines where the target release is set either globally or per-job within the CI configuration file.

the calculcate

• override the RELEASE when manually triggering a pipeline
• override the RELEASE on a per-job level (via debian/salsa-ci.yml)
• permanently override the RELEASE on a per-pipeline level (via debian/salsa-ci.yml or a project variable)

basically this means that the we only should use the calculated release if it snot defined otherwise.

the problem is the variable precedence rules (i've added related bug-reports to the list):

The order of precedence for variables is (from highest to lowest):

1. ...

2. Manual pipeline run variables (!486 (closed))

3. Project/Group variables

4. ...

5. ...

6. Variables from dotenv reports. (#186 (closed), !346 (merged))

7. Variables defined in jobs in the .gitlab-ci.yml file. (!346 (comment 479542))

8. Variables defined outside of jobs (globally) in the .gitlab-ci.yml file. (!346 (comment 479542), #348 (closed))

9. ...

afaict what we really want is to move the precedence of a single variable from dotenv reports (because this is the only way to dynamically calculate the RELEASE) down below #8 (which i think is the lowest precedence any user will ever set; but in any case moving the precedence down to the very end is also ok)

the question is: how?

Related: #348 (closed)