draft: feat: expose special pipeline variables and deprecate commit info

this is preparation for #23

when creating the pipeline-file for the child pipeline, we use certain env vars that exist only during the pipeline running on gitlab.

For example we use $CI_MERGE_REQUEST_IID to determine the current merge request id and to actually check whether we are in a review pipeline.

this id is then used to create a review-branch url. This information is typically in the context.commitInfo property

The obvious problem with this is, that when you want to create the pipeline locally, you won't have this information. The pipeline file should be independent of the current branch, etc.

A first step there is to reduce the usage of those variables when creating the pipeline.

this mr doesn't aim to alter the execution model yet, but to reduce the usage of this commitInfo.

The idea how this is achieved is to instead of using the values directly, say the current merge-request slug (mrXX), to use the bash variable representation of it until its actually executed in the script.

For example look the change in the snapshots:

the actual string values are replaced with the bash expressions that would return those values.

There is actually a challenge. Consider this expression:

pan-test-app-review-SBUILD_INFO_REVIEW_SLUG-api

for example cloud run deploy requires the name to be lower case. So you can't just lower case this string above (that would even break the variable).

instead of lower casing this, we have to do this: $(echo "pan-test-app-review-SBUILD_INFO_REVIEW_SLUG-api" | awk '{print tolower($0)}')

So i introduced a class BashExpression that can hold such strings and provides some operations on it. E.g. toLowerCase() will create an expression like above instead of lowercasing the string itself.

its not final and untested. Also there is another challenge:

in cases like gitlab's environment.url in the pipeline you can use variables, but you can't use expressions like above.

There is a way of doing that: https://docs.gitlab.com/ee/ci/environments/#set-a-dynamic-environment-url

i implemented that but its untested. Its a bit verbose in the pipeline file.