Add GitHub Action to track doc-en merged PRs

[lacatoire]

Summary

• Daily workflow (6h UTC) that checks the last 7 days of merged PRs in php/doc-en and creates issues in doc-pt_br listing the PT_BR files that need updating
• Stateless deduplication via issue search (no duplicate issues)
• Skips [skip-revcheck] PRs automatically

Inspired by php/doc-fr#2479

[alfsb]

• Daily workflow (6h UTC) that checks the last 7 days of merged PRs in php/doc-en and creates issues in doc-pt_br listing the PT_BR files that need updating

To consider. Instead of creating many issues for each merge on doc-en, create at most one issue on translations, and mutate it with the listing of the updated result of script. So:

• If there is a sequence of doc-en merges that affect the same file, this outdated file name appears only once;
• If the issue gets big with many comments, translations can close it, and a new clean one is opened;
• Having issues and listed files having a N:N relation, these unconsolidated lists of outdated files are very hard to coordinate.

• Stateless deduplication via issue search (no duplicate issues)

As above, the problem may not be due to duplication of issues, but the duplication of file names in many issues.

• Skips [skip-revcheck] PRs automatically

There is a problem in [skip-revcheck] position in messages. In modern usage, [skip-revcheck] in the start of commit messages is always correct, and [skip-revcheck] in the middle of commit messages is always wrong. For example, when a reversion includes the messages of reverted commits, some messages containing [skip-revcheck], then all reversion get skipped, that is wrong.

There exists php/doc-base#181 , that was not merged until now because this change is not unanimous.

---

I can change the doc-base/scripts/translation/configure.php to generate a file named doc-base/temp/translation.need.sync, with the listing of files needing translations. So this script can be simplified to running this configure.php, check if the file was created or not, and if it was created, then mutating or opening an issue with the file contents.

Or better yet. I can change doc-base/scripts/revcheck.php to create this file, so the the script sub runs doc-base/configure.php and doc-base/scripts/revcheck.php, checks for failures of both and the file creation to mutate or open a fixed issue, containing:

1. The output of these scripts, if they failed;
2. The contents of translation.need.sync if translation.need.sync was created;
3. Or better yet, the contents of revcheck.html or an iframe https://doc.php.net/revcheck.php , instead of the simple file listing.

[alfsb]

Agora entre a gente. O que vocês preferem. Um issue por merge no doc-en? Um issue único, aberto ou atualizado quando os scripts falham ou geram lista de arquivos desatualziados?

De minha parte eu acharia mais útil o segundo caso, com um link e um iframe apontado para o doc.php.net/revcheck.php.