The Oniro pipeline is a bit special, because it has to cope with several layers
of git repositories. On one hand side oniro.git uses git-repo manifests, this
presents the first complexity of a branch trying to change the manifest that
needs special care to test correctly (so that the test correctly verifies the
change, rather than previous, known-good commit). On the other hand side it can
be used as a reusable pipeline in other repositories that are described by the
manifest naturally have distinct projects with their own pipelines.

As a sort-of special case, oniro.git fits both of those conditions. Changes to
oniro.git need to both replace the manifest checkout stage (repo init && repo
sync) _and_ replace what the manifest would have checked out to instead use
what GitLab wants to check out inside $CI_PROJECT_DIR.

This presents us with a puzzle, what _did_ GitLab runner do? What exactly is
checked out in $CI_PROJECT_DIR? This depends on project settings, pipeline type
and perhaps other things we have yet to encounter.

Instead of trying to correctly model all the variants, let's do something
stupid and brutal, but correct. When the pipeline indicates that manifest
element needs to be replaced by setting $CI_ONIRO_GIT_REPO_PATH to a non-empty
value then remove the git checkout prepared by git-repo and replace it with a
symbolic link to $CI_PROJECT_DIR.

This allows us to work with merge trains, pipelines for branches and pipelines
for merge requests all at the same time.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>