Join adjacent character data into one text node per run

[gthb]

What

The DOM builder creates a separate text node for each character-data token, so entity and character references and CDATA sections split the surrounding character data into adjacent sibling text nodes:

let package = sxd_document::parser::parse("<a>A&amp;B</a>").unwrap();
let doc = package.as_document();
let a = doc.root().children()[0].element().unwrap();
assert_eq!(a.children().len(), 3); // text "A", text "&", text "B"

The cause: add_text_data does create_text + append_child once per CharData/CData token and once per decoded reference from ContentReference.

This PR joins each contiguous run of character data into a single text node during parsing.

Why

The split doesn't seem deliberate or desired:

• it preserves no information; references are decoded during parsing, and the DOM has no node kinds for entities or CDATA sections.

• it departs from attribute values, which already coalesce into a single string.

• it violates the XPath 1.0 data model, which sxd-xpath consumes directly from this DOM. XPath 1.0 §5.7 (Text Nodes):

  As much character data as possible is grouped into each text node: a text node never has an immediately following or preceding sibling that is a text node.

In sxd-xpath, the split breaks both correctness and performance of text()-based expressions:

• contains(text(), "needle") converts the text() nodeset to a string by taking only the first node in document order, so it tests only the first fragment, missing any content after a reference.

• For nodesets with more than one node, Nodeset::document_order_first rebuilds a document-order index of the entire document per evaluation (Computation of document order needs to be cached sxd-xpath#121). With split text nodes, every entity-bearing element takes that path.

Real-world impact: scanning a 40 MB spreadsheet worksheet XML (in xlpath) with ~35k formula elements containing "/> for //f[contains(text(),"OFFSET(")]-style queries:

• before: over 6 minutes before being killed, missing matches wherever the needle followed a reference;

• after: ~7 seconds, with more correct results.

(This does change the node count/identity that consumers observe. But code that relies on that split ... probably shouldn't :))

How

Buffer character data instead of emitting text nodes, in the DOM builder. Flush and emit a text node when a child element, comment, or processing instruction interrupts, or when the containing element closes.

Add tests covering coalescing across references and CDATA, and runs legitimately split by a comment or a child element.

Update three existing tests which asserted the split.

Out of scope

Could add a DOM-style Node.normalize() API, complementing this, since adjacent text nodes can still be constructed programmatically via repeated append_child(create_text(..)). But parse output seems worth fixing regardless.