This was mis-fixed in c190b32 which encoded the Ruby strings as
unicode to fix the previous bad encoding which dated back to the
original Instiki that should have single-quoted the CSS unicode
strings.

Specifically the patch that affects this behavior is

  nokogiri/patches/libxml2/0002-Update-entities-to-remove-handling-of-ssi.patch

which was introduced to avoid server-side-include vulnerabilities, see

  sparklemotion/nokogiri@4852e43

see release notes for Nokogiri v1.13.5

Addresses CVE-2022-32209

…ombination_v1.4.x

prevent combination of `select` and `style` tags with the HTML4 parser

Related, see:

- sparklemotion/nokogiri#2625
- https://gitlab.gnome.org/GNOME/libxml2/-/issues/380

backport CI fixes to stay green with latest libxml2

because the 22.04 has a version with 4fd69f3 but not e986d09 from
2.9.14 and that's causing leading `<` to be parsed differently.

i'd fix it better than this, but I think only 2.9.13 has this behavior.

which uses the Crass parser

which correctly sanitizes data URL mediatypes

to prepare for a better fix

Also, notably, document the decisions behind this approach in a
decision record.

v2.19.1 has the new methods we're using:

- Loofah::HTML5::Scrub.cdata_needs_escaping?
- Loofah::HTML5::Scrub.cdata_escape
- Loofah::HTML5::Scrub.scrub_uri_attribute
- Loofah::HTML5::Scrub.scrub_attribute_that_allows_local_ref

avoiding code duplication in this gem.