Redesign to be more suited for feeding parsed input back into output

[ssokolow]

Currently, the reading and writing APIs are oddly asymmetrical, with reading being a pull-parser with textual node names, and writing being a DOM-style API requiring strongly typed tags.

This makes it very difficult when one wants to do something like taking an SVG file with pre-defined node IDs that was composed graphically in Inkscape, insert some stuff generated programmatically from a data source, and then write the output to a new SVG file.

Heck, I'm finding it hellishly annoying just trying to create an identity function which transforms the pull-parser input to the DOM output because:

1. I don't see any way to go from the tag name strings in Event::Tag to valid output without manually mapping them back to Node impls using a big match statement.
2. Because dyn Node is unsized, Box<dyn Node> doesn't impl Node, and your DOM is immutable once constructed, I feel like I have to implement my own intermediate AST just to get the two halves of the same crate to talk to each other.

With the current state of the APIs, it feels as if there's no point to forcing people to download the reader to get the writer or vice-versa, and it's just not worth it to try to get any form of compile-time correctness for SVG beyond what an XML crate without DTD validation would give me.

[IvanUkhov]

Thank you for the feedback! Yes, it is fair criticism. If you have any working ideas, I would be happy to review a pull request and eventually update the API.

[fenjalien]

This should be tracked in a separate issue but seems good to mention it here. What about adding support for the lyon crate(https://github.com/nical/lyon)? It has a great looking path module that supports SVG like commands https://docs.rs/lyon_path/0.17.2/lyon_path/

[clouds56]

Shall we have a enum that contains all type of nodes that implement Node