merge-updates: Set $REBASE_RANGE to rebase changes instead of merging

When downstreams need to mirror our packaging repositories they need to pull the latest but also preserve the downstream changes they introduced.

For instance assume that a downstream has a downstream/v2021 branch that is based on apertis/v2021-updates (based on Buster) plus some customization and needs to mirror apertis/v2022dev3 (based on Bullseye) while preserving the customization.

Naively doing a merge would hit conflicts since the apertis/v2021-updates has diverged from the point where apertis/v2022dev3 has been branched, and the Buster updates would not apply on the Bullseye-based branch.

The most sensible option is to rebase the changes: if there are no downstream changes (the most common case) this becomes a no-op and the process can proceed easily, otherwise it still has a good chance to be able to apply simple customizations.

Use the newly introduced --rebase-range flag only when explicitly told to do so. During mirroring, the orchestrating job will ensure that the $REBASE_RANGE variable is set for the pipelines triggered on each packaging repository.