(cherry picked from commit 30600ac)
(cherry picked from commit fff9467)

This way it's a bit more centralized and easier to extend.

(cherry picked from commit 6054a8f)
(cherry picked from commit 290b336)

(cherry picked from commit 3dff9c3)
(cherry picked from commit 5b8b570)

Instead of failing the job, the workflow will now post review comments
as "Request Changes". This makes the feedback more readily visible and
avoids having to merge despite a failing CI job. It is also a
pre-requisite to enable required status checks / required workflows in
the future.

Committers are asked to confirm the differences by explicitly dismissing
the generated review. After dismissal, the related review comment will
automatically be marked as "resolved".

The comments only report warnings and errors. Reviews are automatically
dismissed when they have been addressed by the author and no problems
remain. If problems remain, existing, still pending, review comments
will be updated. If the same problems had already been dismissed
earlier, no new review comment will be created either.

(cherry picked from commit 515b174)
(cherry picked from commit c971f0d)

GitHub comments have a length limit, so we can't just dump everything.
The 10k limit is arbitrary, but the assumption is that reviewing the
range-diff is not the sensible thing to do once it becomes a certain
size - reviewing the regular diff and treating the commit as "new" is
easier to do in that case. Thus, truncating should work out fine,
especially when the full range-diff is still available in the runner
log.

This could still end up in with an error, if a PR has multiple commits,
which all hit the limit. Let's get there first, before we try to fix
that hypothetical case, too.

(cherry picked from commit 856792f)
(cherry picked from commit 343e17a)