update readme

## Usage

For both repositories (ivas-codec and ivas-basop), there should be one main yml file in here which includes stuff from `includes`.

Ideally, there is no other CI code in the respective repositories except a minimal `.gitlab-ci.yml` file which includes from here (currently only achieved for ivas-basop), e.g. (from ivas-basop):

There is no other CI code in the respective repositories except a minimal `.gitlab-ci.yml` file which includes from here, e.g. (from ivas-basop):

``` yaml

variables:

This way, any CI change can be developed centrally in this repository and does not need to be merged/ported to different repositories/branches.

### Adding new CI code

### Adding a new job

In general, job definitions should go into `main-float.yml` or `main-basop-yml` if they are specific to one of the repos.

Shared jobs should go into `includes/`.

It might also be helpful for bundling stuff together to put repo-specific code into `includes/` as well.

The workflow and rules section for each CI config are located at the top of the respective `main-*.yml` file.

After implementing your job, adapt or add there so that your job runs when desired.

Prefer adding scripts in `snippets/` over yaml anchors.

Also check the [guidelines](#some-guidelines-hints) below.

For shared jobs, it might be needed to check in which project the CI is running.

You can do that by checking the gitlab-predefined `CI_PROJECT_ID` variable against `PROJECT_ID_FLOAT` and/or `PROJECT_ID_BASOP`, e.g.:

``` yaml

script:

    - |

      if [ "$CI_PROJECT_ID" == "$PROJECT_ID_BASOP" ]; then

        bash "${CI_PROJECT_DIR}"/ivas-codec-ci/snippets/basop/update-scripts-repo.sh

      fi

```

### Testing new CI code

1. Implement your new CI code on a branch in this repo, e.g. `add-awesome-test` and ideally add a merge request for easier review.

2. Test it by opening a branch in the respective ivas-* repository and changing IVAS_CODEC_CI_REF to your WIP branch, so the yaml there should read:

### Some guidelines/hints

- use only one include section at the top of the main yml file to keep things clear, remember that later stuff overwrites earlier stuff

- in general prefer adding scripts here over using yaml anchors in a CI config file

- if your script shall modify some environment variable, you need to run it with `source` instead of calling it.

- the merge CI config in the ivas-* repos can be viewed in the pipeline editor under "full configuration" - this is especially useful when making changes which should not functionally affect the CI, then it is helpful to copy the full merged config with and without the changes and compare the files directly or as parsed yaml dict locally.