GH Actions: add some additional XML validation checks

* Check the docs against the schema from PHPCSDevTools.
* Check dev tool config files.

Author: jrfnl

.github/workflows/NOTES for release.yml

@@ -0,0 +1,32 @@
+NOTES:
+
+Check how they do it in....
+* PHPUnit
+* PHPDocumentor
+* PHPStan
+
+* Still also needs the (slimmed down) release checklist for the manual steps
+
+* basic principle: trigger a release build on closing a milestone.
+  !!! ONLY RUN on this repo!!!
+  -> see if any of the "prelim" tasks can be automated (like checking for squizlabs `@license` tag)
+  - create a tag
+  - create the phars
+  - run the tests
+  - sign the PHAR files
+    -> will need to figure out if this step will fail (correctly) if the signature needs renewal. If not, will need a check before this to check if the signature is still valid
+  - attest the signatures too ?
+  - verify PHAR attestations
+  - create the GH Pages update
+    -> will probably need a script to update the phive.xml file
+  - commit & build GH Pages
+  - verify the site has been updated
+    - download phar file and check phpcs -v against tag
+    - do test install with phive and verify installed versions
+  - create a draft release for the tag and upload the phar + asc files to it
+  - ??? can probably not do the update of the version nr to next as doesn't know what the "next" version should be...
+
+
+* will need a think about if and if so, how the PHAR building job can be made re-usable
+* will need a think about whether `test` should still run on `tag` as if the tag is created by a workflow, I highly doubt it will trigger a run
+    => and if so, may need to have a think about making the test workflow reusable too, including whether this can be set up to handle code coverage in the same re-usable workflow

.github/workflows/NOTES release verification.txt

@@ -0,0 +1,68 @@
+Workflow - things to think through:
+
+* Release vs pre-release
+
+* On release vs manually triggered
+
+=> The `latest` tag determination is probably not necessary when running on "release".
+   Info should be available in the `github` context -> needs checking
+   If so, those steps could be made conditional on "workflow triggered".
+
+=> For pre-release, we need to skip the `verify-plain-web` job as that should always hold the latest release, not pre-release
+   The other jobs should still run.
+
+=> For workflow triggered....
+   -> We need to check if the latest release is a release or pre-release.
+      If release, all good, continue as normal.
+      If pre-release, the plain web check needs to be skipped ?
+      Or should it try and find the latest _stable_ release and try and verify that instead ?
+
+------------
+
+=> See about moving the "determine the tag" part to a separate job and carrying a variable over to the next jobs
+
+
+
+
+
+
+
+
+
+
+=================================================================================
+
+NOTES:
+
+Check how they do it in....
+* PHPUnit
+* PHPDocumentor
+* PHPStan
+
+* Still also needs the (slimmed down) release checklist for the manual steps
+
+* basic principle: trigger a release build on closing a milestone.
+  !!! ONLY RUN on this repo!!!
+  -> see if any of the "prelim" tasks can be automated (like checking for squizlabs `@license` tag)
+  - create a tag
+  - create the phars
+  - run the tests
+  - sign the PHAR files
+    -> will need to figure out if this step will fail (correctly) if the signature needs renewal. If not, will need a check before this to check if the signature is still valid
+  - attest the signatures too ?
+  - verify PHAR attestations
+  - create the GH Pages update
+    -> will probably need a script to update the phive.xml file
+  - commit & build GH Pages
+  - verify the site has been updated
+    - download phar file and check phpcs -v against tag
+    - do test install with phive and verify installed versions
+  - create a draft release for the tag and upload the phar + asc files to it
+  - ??? can probably not do the update of the version nr to next as doesn't know what the "next" version should be...
+
+
+* will need a think about if and if so, how the PHAR building job can be made re-usable
+* will need a think about whether `test` should still run on `tag` as if the tag is created by a workflow, I highly doubt it will trigger a run
+    => and if so, may need to have a think about making the test workflow reusable too, including whether this can be set up to handle code coverage in the same re-usable workflow
+
+

.github/workflows/validate.yml

@@ -42,11 +42,24 @@ jobs:
           pattern: "./src/Standards/*/ruleset.xml"
           xsd-file: "phpcs.xsd"
 
-      # Validate the basic well-formedness of the Documentation XML files.
+      # Validate the Documentation XML files.
       - name: Validate documentation XML
         uses: phpcsstandards/xmllint-validate@v1
         with:
           pattern: "./src/Standards/*/Docs/*/*Standard.xml"
+          xsd-url: "https://phpcsstandards.github.io/PHPCSDevTools/phpcsdocs.xsd"
+
+      # Validate dev tool related XML files.
+      - name: Validate Project PHPCS ruleset against schema
+        uses: phpcsstandards/xmllint-validate@v1
+        with:
+          pattern: "phpcs.xml.dist"
+          xsd-file: "phpcs.xsd"
+
+      - name: "Validate PHPUnit config for well-formedness"
+        uses: phpcsstandards/xmllint-validate@v1
+        with:
+          pattern: "phpunit.xml.dist"
 
   xml-cs:
     name: 'XML Code style'
@@ -80,6 +93,7 @@ jobs:
       - name: Check XML code style
         run: |
           diff -B ./phpcs.xml.dist <(xmllint --format "./phpcs.xml.dist")
+          diff -B ./phpunit.xml.dist <(xmllint --format "./phpunit.xml.dist")
           diff -B ./src/Standards/Generic/ruleset.xml <(xmllint --format "./src/Standards/Generic/ruleset.xml")
           diff -B ./src/Standards/MySource/ruleset.xml <(xmllint --format "./src/Standards/MySource/ruleset.xml")
           diff -B ./src/Standards/PEAR/ruleset.xml <(xmllint --format "./src/Standards/PEAR/ruleset.xml")