feat: allow propagate custom output variables

Then at service binding, the application gets the three credential parameters as specified in the descriptor file, that are `user`, `password` and `url`.

### Deployment output variables

Each deployment job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#artifactsreportsdotenv)):

* `$environment_type`: set to the type of environment (`review`, `integration`, `staging` or `production`),

* `$environment_name`: the application name (see below),

* `$environment_url`: set to the environment URL (whether determined statically or dynamically).

Those variables may be freely used in downstream jobs (for instance to run acceptance tests against the latest deployed environment).

You may also add and propagate your own custom variables, by pushing them to the `cloudfoundry.env` file in your [deployment scripts](#hook-scripts).

## Variants

### Vault variant

    # finally persist environment url

    echo "$CI_ENVIRONMENT_URL" > environment_url.txt

    echo -e "environment_type=$environment_type\\nenvironment_name=$environment_name\\nenvironment_url=$CI_ENVIRONMENT_URL" > cloudfoundry.env

    echo -e "environment_type=$environment_type\\nenvironment_name=$environment_name\\nenvironment_url=$CI_ENVIRONMENT_URL" >> cloudfoundry.env

  }

  function pre_delete() {