GH Actions/publish-wiki: auto-generate table of contents

[jrfnl]

This commit adds steps to the workflow to auto-generate a GitHub wiki compatible table of contents in most wiki pages.

This reduces the risk of a TOC being out-of-date or containing incorrectly formatted links, as well as reduces the maintenance burden.

This action uses the doctoc pages to generate the table of contents and this can be tested locally using the same steps as used in the GH Actions workflow:

npm install -g doctoc
cp -v -a wiki _wiki
doctoc ./_wiki/ --github --maxlevel 4 --update-only
doctoc ./_wiki/Version-4.0-User-Upgrade-Guide.md --github --maxlevel 3 --update-only

Notes:

• The files are copied to a _wiki directory - which is .gitignored - before pre-processing to reduce the risk of the source files being accidentally updated (and committed), which would undo the automation.
• The --github flag puts the TOC generation in GitHub compatible mode.
• The --update-only flag means that only markdown files containing the <!-- START doctoc --> and <!-- END doctoc --> markers will be updated and files without those markers will be left alone.
• By default, the TOC will contain all headers up to the indicated --maxlevel. For the V 4.0 Dev upgrade guide, this looked weird, what with some "Upgrading" headers being at level 4 and some at level 5. To mitigate this, a couple of headers have been turned into "bold phrases" instead. Along the same lines, for the V 4.0 User upgrade guide, the level 4 headers were always "Upgrading". Those belong with their parent heading and IMO do not need to be separately called out in the TOC, which explains the second call to doctoc to overrule the TOC for that file specifically with a --maxlevel 3 setting.
• The start/end markers have been added to all files which contained a TOC, except for one: Reporting.md. The reason for this exception is that the section order in the file does not match the current TOC order, with the existing TOC order making sense from a TOC point of view, while the section order makes sense from a "types of reports most used" point of view. Whether this page should be re-organized or not, is outside the scope of this PR.

To allow contributors to review the resulting pre-processed wiki files, the files are uploaded as an artifact when a PR dry-run is being executed and a comment is posted on the PR requesting the contributor to review the pre-processed files.

Includes adding a TOC to the Coding Standards Tutorial page and adding "back to top" links within the page.

Ref:

• https://github.com/thlorenz/doctoc

[jrfnl]

Thank you for your PR.
A dry-run has been executed on your PR, executing all markdown pre-processing for the wiki files.

Please review the resulting final markdown files via the created artifact.
This is especially important when adding new pages.

N.B.: the above link will automatically be updated when this PR is updated.

[jrfnl]

Hmm... looks like the PR comment is posted with me as commenter because the secrets.COMMENT_ON_PRS_TOKEN Personal Access Token being used to allow for commenting on PRs was created from my account. Not sure I really like that, but also not sure how I could change it.

[jrfnl]

Switching to use ${{ secrets.GITHUB_TOKEN }} for the repo_token would switch the account to Github[bot], however, that may prevent the adding of comments to PRs coming from forks (when the comment would be all the more relevant).

Maybe let's start with ${{ secrets.GITHUB_TOKEN }} and then once this is merged, either @rodrigoprimo or @fredden could submit a PR from a fork to see if the comment shows up ?