XML: regression.sh + upgrade-2.10.xsl + test-2: browser-based test drive

This leverages several facts:

1. beside XSLT, XPath standalone W3C standard ("recommendations"), there are also some integrations bits being specified:
   • https://www.w3.org/TR/xml-stylesheet/, without regulating specifics of particular kinds of "stylesheets", which is then covered in
   • https://www.w3.org/TR/xslt-10/#section-Embedding-Stylesheets that explains how embedding using the above provision is supposed to work, which is also semi-supported in
   • https://html.spec.whatwg.org/multipage/scripting.html#scriptTagXSLT, the "HTML Living Standard"
2. apparently[1], popular web browsers are "xml-stylesheet processor"[2] compliant for quite some years, so that when they process XML documents, they will consider "xml-stylesheet processing instruction"[3] and possibly fetch referenced XSLT stylesheet and run the respective transformation, presenting the result in place of the original, unprocessed content
3. it's feasible to have XSLT produce HTML-encoded copy of the input (see, e.g. https://github.com/Boldewyn/view-source, from which two files are borrowed here)
4. moreover, it's feasible to have such a verbatim-to-HTML-encoded-copy applied to the result of another transformation like upgrade-2.10.xsl with the use of XSLT extension functions from EXSLT project (http://exslt.org/exsl/functions/node-set/index.html)
5. and last but not least, the result the overall XSLT stylesheet transforming the original XML file can, indeed, be full-fledged XHTML, incl. javascript references, asynchronous HTTP requests, etc.

Based on the above point, it was possible to implement new master
template, upgrade-2.10-htmldiff.xsl, that will produce XHTML page
containing:

• verbatim-to-HTML-encoded-copy of the original XML (see 3.)
• verbatim-to-HTML-encoded-copy of the original XML on which upgrade-2.10.xsl pacemaker's ugprade procedure was applied (see 3. + 4.)
• glue JavaScript code so as: . to invoke external client-side script to compare the above two intermediate outcomes -- diffview.js from https://github.com/prettydiff/prettydiff" is being used, but not to complicate licensing matter and because that file is used only for maintenance, installation-less purposes, the file will get one-off downloaded and cached on demand (and in turn, it's banned in .gitignore) . when the source XML comes from a location resembling xml/test-2 in-tree path, to fetch expected diagnostic messages from the file with extension changed to ".ref.err", and to offer links and arrow-based navigation to next and previous such test case (within the same hierarchy level) . some other minor visual enhancements

The whole arrangement has a simple purpose: to simplify comprehension
of the upgrade validation test suite, which is, furthermore, performed
on-the-fly directly by XSLT means of the web browser pointed at
particular source XML file -- they go annotated with xml-stylesheet
processing instruction referring to said master XSLT template
accordingly. The whole process is then wrapped in

./regression.sh -W test2to3

like invocation, which will simply run the Python standard library
backed HTTP server using xml subtree as it's root (see also commit
156623a22) where the web browser is subsequently navigated.

The secondary, future anticipating purpose is to provide a practical
application demonstrating how severity in-band marking can be
leveraged in the stream of diagnostic messages (here, applied on
asynchronously fetched pre-existing baseline -- best what can be
done here, see below).

Few other observations from practical use of this with Firefox:

• Firefox will produce the native diagnostic messages arising from XSLT processing to the JS console, with "xsl:message -" prefix (there's also no documented API to fetch these messages back to client side scripting, otherwise they could be presented right away, possibly diff'ed with the expected ones)
• Firefox doesn't allow the whole "XML -> transformation -> page referencing other resources (regardless where located)" out of the box when accessing the XML through "file://" prefixed URI
  • one possibility, possibly risky hence rather avoided, would be to tweak security.fileuri.strict_origin_policy browser's setting, but more acceptable solution was taken with regression.sh per above (run the ephemeral web browser and access from here) instead

Known issues:

• view-source/original.xsl is too keen when it comes to HTML entities like " within XML comments so they are then rendered in this exploded form; not sure if bug or feature, possibly fixable by the means of extra JavaScript pass
• prettydiff/diffview.js is too keen when it comes to whitespace, so the diff doesn't show representative formatting of the inputs, but still does a great job in visualising the actual impact of the upgrade

[1] http://test.greenbytes.de/tech/tc/xslt/
[2] https://www.w3.org/TR/xml-stylesheet/#dt-xml-stylesheet-processor
[3] https://www.w3.org/TR/xml-stylesheet/#the-xml-stylesheet-processing-instruction