feat: implement #890 and definitely solve #849

[EDM115]

Based on the plan I wrote at #849 (comment) with a few tweaks

Proposed workflow moving forward

• The master branch would only include the code for the latest release version of cloc
• Any development would occur in a separate branch called release-vX.XX and named after the next stable release (ex here : release-v2.06)
• Once the development is done, a PR to merge the branch into master would need to be created with the label release-ready
• An action is ran which does the following :
  • Edits the version in cloc and Unix/cloc, no need to do it manually
  • Build the .exe in a neutral environment (fixes [BUG] cloc won't work if ran through a symlink on Windows (ex Winget) : Can't locate PAR.pm in @INC #849)
  • Upload the .exe to VirusTotal for analysis and grabs the URL
  • Posts the .exe and VT URL in a PR comment (useful for checks)
  • Edits the README.md with new version in the badge, commands, references to files and adds the VT analysis and the release date
  • Edits the Unix/NEWS file with the body of the PR (contains release notes) and formats them according to older news entries
  • Commits the changes
• Once the action finished to run and the commit is made, the PR is ready to merge
• Merging the PR runs another action which does the following :
  • Grabs the .exe from the latest matching PR comment
  • Creates the necessary release artifacts
  • Publish the release with the PR body as description, artifacts and title + tag matching the naming of previous releases

Requirements

• Need to create an Action Secret called VIRUSTOTAL_API_KEY (check https://github.com/AlDanial/cloc/settings/secrets/actions/new), API key available at https://www.virustotal.com/gui/user/USERNAME/apikey
• Need to create a new Label called release-ready (check https://github.com/AlDanial/cloc/labels)

Last notes and caveats

• The VirusTotal API won't cause any problem here, unless you do 4 releases per minute/500 per day, which is very unlikely 😄
  Note that out of the 2 used endpoints (file_upload and analyses), only the first one counts towards the quota
• The actions are designed in such a way that if you created the PR but need to do some fixes, you can push them to the release-vX.XX branch and remove/re-add the release-ready label.
  The action will re-run with the latest code changes, and the second action is made to retrieve the last PR comment matching the patterns
• Although simple and double quotes are allowed in the PR body, certain markdown formatting characters (*, `, _) will be stripped from the Unix/NEWS file for PowerShell syntax reasons and to match the formatting of older entries.
  This means that "VIRUSTOTAL_API_KEY" will be rendered as "VIRUSTOTALAPIKEY".
  Previous releases don't have any of these 3 characters but it's something to keep in mind.
• Created artifacts (that holds temporarily the built .exe) are retained for 90 days by default (maximum value), which is more than enough
• There is no simple way to restrict the merge of the release PR while the action hasn't finished to run.
  We could go over-the-top and add another action triggered by the release_staging one, with a branch ruleset on master that checks for this specific action success, but it's maybe too much.
  So keep in mind that merging the PR before the first action finished to run will break the functioning of the second one.
  The PR comment + commit with the changes is the thing to wait for.

Although it is a proposed solution, it may not be definitive nor tailored to your needs, so tell me if this needs changes.

[AlDanial]

Wow, I'm blown away. This is one of the most helpful PRs in cloc's history, thanks! Lots for me to do--get used to the branching strategy behind this, get API keys, set up the secrets. It will be exciting to see exe's built automatically for sure, better still if they pass the winget test.

[EDM115]

thanks, I'm happy you liked my implementation :)
I can confirm that the built .exe works perfectly fine with Winget
you can see an example PR here, with body formatting, automatic comment and the commit afterwards which edits the files. an example release can be found here (yes version is high because I had a lot of trial and error)
and here's an example of re-running the action after changes. you can also see the failed attempts 😄