[Feat] CI: improve Periodic update workflow

[nilason]

Is your feature request related to a problem? Please describe.

The recent addition of the CI workflow Periodic update
and in particular the job update-configure, which creates a pull request with updates of the files config.guess and config.sub if available, has revealed some unexpected particularities of its functionality, #3289:

1. The CI checks are not run automatically on the created PR
2. The 'committer' is apparently automatically me (!), possibly because I was the one doing the latest change to the workflow file.

Describe the solution you'd like

See https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#triggering-further-workflow-runs for background and suggestions to workarounds/solutions to this issue.

I myself lean to the solution of creating and using a machine account, possibly under OSGeo (eg. 'OSGeo[bot]'), which is the quasi 'committer' of the PR (in a similar way 'renovate[bot]' now is committer for the CI updates).

Describe alternatives you've considered

We can leave things as they are, the checks may be triggered by close/re-open the PR, and it doesn't matter for me who is the committer for that configure-files update. Such an update is not so frequently released to be a real nuisance.

[echoix]

I found something: https://github.com/github/codeql-action/blob/f055b5e672ed1ea4fd98a276788e4bcb5a64ad17/.github/workflows/check-expected-release-files.yml#L3-L10

Here they use ready_for_review as an additional activity type to the default for pull_request of opened, synchronize, and reopened.

That would mean that putting a PR as draft and then back to ready to review would do the same thing as closing and opening, but without the emails sent and without side effects for things like dependabot/renovate that act when a PR is closed. Since we use concurrency groups and cancel in progress, if on another PR a user puts a PR to draft then sets it ready to review while the checks haven't finished yet for the same commit, it will cancel the previous running jobs and run again finished jobs. Since it's still the same commit, it's a bit useless. With the velocity we have, an old PR wouldn't stay up to date without needing to merge main again/rebase. But if no commit has been made to main (sometimes 3-5 days pass before another burst), and a new automatic PR happens, merging main into that PR isn't possible. So this additional activity type is still a valid option.

And even if it is possible to start a useless set of CI checks with it, when we reopen/ready to review for a same commit, we may be merging main back to it, thus cancelling that set on CI runs.

[nilason]

For reference: QGIS make use of https://github.com/qgis-bot, for some automatic procedures.