formalise post-build tests

[finanalyst]

There was an issue when highlight syntax was not loaded and this was not picked up in a timely manner.

There is a milestone for reporting in the Collection build process. Currently, some reports are generated about links, plugins, and so on.
The design intention was to create plugins that would test the files.
Currently, the system checks all internal links, and it could check external ones. The external link checks are disabled because it takes an extra 5 minutes to run through them all.
In addition, the internal checks are creating a few false negatives, so that needs fixing.

@coke in addition to a check on syntax highlighting, local links (by which I mean between inside all the documents in the documentation suite), and internal links (links within the same file), what other tests on the built documents need to be run.

@dontlaugh, @coke if a test fails, should the whole build fail?
Or should we have a Warning that puts a message in the logs, and a Fail that stops the build?

Eg. A bad link to another file that does not hit an anchor could be a Warning rather than a Fail.

These tests are different to the tests already run on the Raku/doc site, which look at content directly, rather than interactions between content files when built.

[coke]

IMO: If a test fails, the build should fail. Pushing out a broken version of the site is worse than not updating the site.

[coke]

the build should fail

Not, however, in the case of external links, which are not under our control. Those can be warnings. If we're checking internal content, we really should be checking those links in the doc site itself where possible, so we catch them as soon as possible.