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)

Start at the `prer` entry point and trace how it reads the current Git ref, commit history, and accumulation branch during a GitHub Actions run. Reproduce the described out-of-order and same-branch scenarios. Done means concurrent executions no longer produce misleading release notes or lose generated changes.

Written by the indexing model from the issue text.