Possible misleading `prer` commit history

`prer` implicitly assumes that is is run in strict order on the commits in the tracked branch. If commits execute in parallel (as is the case if its run in Github Actions) there is no guarantee that these will complete in order. This can lead to generated release notes missing commits from which they do contain changes, or referencing commits from which the changes are not included.

Let's assume `prer` is run in a GithubAction workflow with two steps:
```
bazel test //...
prer
```
Two commits which modify different services: `A-B`, and begin workflow execution. For the sake of example, assume the test step takes twice as long for `A` as it does for `B`. `B` completes, renders manifests, see changes and pushes to the PR branch all of the changes it produced (from both A and B). `A` completes, renders manifests, sees no changes and does not push to the PR branch. In this example changes from both `A` and `B` are included but the notes only contain a reference to `B`.

Taking the same example, but this time assuming that `A` and `B` modify the same service. In this case when `A` completes it will see changes (since B's changes include A's but A's dont include B's) and commit them. In this case, the release notes will reference both A and B (though in reverse order) however the changes in the output will only be build as of A. The changes from B will ultimately be included by the next commit (which plays out like the example above).

This scenario can be checked by `prer`. When it looks at the git log as of its current ref it can decide:
* if this commit is ahead of the commit for which im running - abort
* if this commit is behind the commit for which im running - include a log of all changes since then, not just the log for the commit im running.

Another possible outcome is that both run and checkout the accumulation branch as of the same commit. This will lead one of the executions to fail when it tries to push this branch. This could be addressed with a retry (which includes the logic described above)

Commencez au point d’entrée `prer` et suivez la façon dont, pendant une exécution de GitHub Actions, sont lus la référence Git actuelle, l’historique des commits et la branche d’accumulation. Reproduisez les scénarios décrits avec un ordre incorrect et avec la même branche. C’est terminé lorsque les exécutions concurrentes ne produisent plus de notes de version trompeuses et ne perdent plus les modifications générées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.