feat: upgrade @xmldom/xmldom to v0.9.5

[KiwiKilian]

I've upgraded @xmldom/xmldom to 0.9.5 and added the types to allow both DOM and xmldom Element/Node/Document. Otherwise the parsing result of the new versions wouldn't be accepted. I'm not sure if there would be a smoother path? Looks weird on the Docs like Document | Document 🤔.

Otherwise I only had to switch Array.from() to [...].

[KiwiKilian]

Might also get resolved by xmldom/xmldom#724 but using the more narrow types of xmldom might be right.

[tmcw]

This is a little problematic: xmldom/xmldom in this PR is still in devDependencies, so it is not guaranteed to be installed when togeojson is installed as a dependency, which will potentially cause an issue when the generated typescript types for this package refer to xmldom/xmldom. So we'd have to include @xmldom/xmldom types, which would bump up this package's dependencies by 156kb.

I think in the medium term, only taking the part of this PR that switches from Array.from to spread syntax would be the best tradeoff, and if xmldom doesn't make a change then people could use as unknown to cast to the xmldom desired types.

[KiwiKilian]

The array spread is also only to resolve type issues.

Wise consideration regarding dependency size. If we keep only import type (removing one value import for the Node Type enum) and move from devDependencies to dependencies it shouldn't harm browser users and only add to developers node_module size. What do you think about this approach?

I think for xmldom to have stricter types is the right move. So using the types within the lib might help to limit to the available functions. And having to use unknown when xmldom is the recommended parser feels a bit off.

[KiwiKilian]

I've updated with my proposal. Another possibility would be to add xmldom as an optional peer dependency. This would require TypeScript users to install xmldom.

[tmcw]

I'm not sure about this overall - it'll take some testing to figure out that if this package introduces @xmldom/xmldom as an optional peer dependency and someone doesn't have it installed, what typescript will do. I suspect TS might produce an error in that case.

Adding @xmldom/xmldom to dependencies doesn't feel right - users shouldn't pay for the package download when they might not even use the provided types. Part of this module's basic premise is that it's zero-deps and tiny, and introducing a big dep would really change that equation.

I'll think about it some more, but having as Document as a recommended strategy might be a little rough but basically have the right tradeoffs. Ideally though xmldom would just produce a compatible Document type :/