Unify custom + extension elements into one arbitrary-element tree

[mmcdole]

Right now unknown elements are handled three inconsistent ways: namespaced elements become the recursive ext.Extension tree, non-namespaced ones on items go into Item.Custom map[string]string (flat, drops nesting and attributes, see #203), and unknown elements at feed root are Skipped and lost.

Consolidate to a single arbitrary-element tree: everything that isn't a known element (namespaced or not, at any level) parses into one ext.Extension-style structure that preserves nesting, attributes, and repetition, with ergonomic accessors (GetValue("a","b") etc.).

This can land in v1 additively: build the tree into a new field and keep Item.Custom as a shim populated from it (leaf text for simple elements, so existing reads are unchanged; nested elements stop corrupting). Removing Item.Custom outright is the only breaking part, and that can wait for a future v2.

Most of this already exists on the v2-custom-elements branch. This tracks finishing and landing it, plus fixing parseExtensionElement while we're in there (the O(n^2) value concat and the raw loop from #9).

Related: #82, #203, #205.

[mmcdole]

Folding in related issues so this is the single tracker for custom-element handling:

• Parsing custom tags in Item #82 - custom tags in items (simple ones land in item.Custom; nested don't)
• corrupted / mangled nested custom XML #203 - nested custom element with CDATA children comes back corrupted (confirmed still reproducing; good concrete test case for the rework)
• Enhance custom element handling #205 - the original design proposal for this

[mmcdole]

Weighing how to land this, not committing to an approach yet.

The capability here — parse every non-schema element (namespaced, non-namespaced, and the root-level ones that are currently Skipped and lost) into one tree, fixing #203 and recovering the discarded data — is achievable in v1 additively: build the tree into a new field and keep Item.Custom as a shim populated from it (leaf text for simple elements, so existing Custom["x"] reads are unchanged; nested elements stop corrupting). The only part that actually needs v2 is removing Item.Custom, which is cleanup rather than capability.

So the open question is narrow: land the tree in v1 behind the Custom shim now, or hold the whole thing for v2 to also delete Custom. Leaning toward v1-behind-a-shim.

Unrelated to this decision: the CDATA text-content loss (#140) is fixed separately in #295. The innerxml-based path for HTML-bearing text fields (title/description) stays correct regardless of how this lands, so it isn't blocked on the tree rework.

[mmcdole]

Two updates from the #333 parser refactor that affect the plan here.

Scope inventory: the "Skipped and lost" bucket is bigger than the body states. Besides the feed root, unknown non-namespaced elements are also dropped at channel level and inside image, textinput, skipHours and skipDays. Only item children reach Custom today.

Implementation note: after #333, every container parses its children through one shared loop (shared.ForEachChild) with a switch per container, so the capture point for the tree is now uniform. Each switch's default case is exactly where the arbitrary-element capture goes, one line per container, instead of threading it through eleven hand-rolled loops. The v2-custom-elements branch predates that refactor and will need rebasing onto the new shape, but the port gets simpler, not harder.