CDATA sections should be allowed at integration points during fragment parsing

https://bugs.webkit.org/show_bug.cgi?id=319474

Reviewed by Anne van Kesteren.

In 310593@main, constructTree() was updated to use the adjusted current node
(instead of the current node) for the integration point checks that compute the
tokenizer's shouldAllowCDATA and forceNullCharacterReplacement flags. That change
correctly fixed a normal-vs-fragment-parsing inconsistency, but it preserved a
long-standing deviation from the specification: it kept both flags coupled to a
single "in foreign content" condition that excludes integration points.

Per the tokenizer's "markup declaration open state"
(https://html.spec.whatwg.org/multipage/parsing.html#markup-declaration-open-state),
CDATA sections are switched into whenever "there is an adjusted current node and
it is not an element in the HTML namespace". Integration points are NOT a
consideration there. Since integration points (MathML mi/mo/mn/ms/mtext and SVG
foreignObject/desc/title) are themselves in the MathML/SVG namespace, CDATA
sections should be allowed when the adjusted current node is an integration
point. This matches Firefox and Edge; Chrome and shipping Safari incorrectly
disallow CDATA there due to shared WebKit heritage. See the discussion in
whatwg/html#4016 (https://github.com/whatwg/html/issues/4016), where the spec was
confirmed to intentionally key only off the adjusted current node's namespace.

The forceNullCharacterReplacement flag is different: it follows the tree
construction dispatcher's notion of foreign content
(https://html.spec.whatwg.org/multipage/parsing.html#tree-construction), which
treats integration points as HTML content and thus must continue to exclude them.

This patch decouples the two flags so each matches its respective specification:
shouldAllowCDATA now depends only on whether the adjusted current node is in a
non-HTML namespace, while forceNullCharacterReplacement retains the integration
point exclusions.

The web platform test added in 310593@main asserted the previous (incorrect)
behavior and failed in spec-compliant Firefox; it has been updated to assert that
CDATA is allowed at integration points, with an HTML context element added as a
control for the disallowed case.

No new tests, updated existing test.

* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/cdata-in-integration-point-fragment-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/cdata-in-integration-point-fragment.html:
* Source/WebCore/html/parser/HTMLTreeBuilder.cpp:
(WebCore::HTMLTreeBuilder::constructTree):

Canonical link: https://commits.webkit.org/317273@main