Merge xilem_html and xilem_svg as xilem_web

[Philipp-M]

Merge these libraries together, as they share a lot of code. xilem_svg is completely merged/ported with xilem_html as xilem_web (name is open for discussion).

The views in xilem_svg were either removed (Clicked or Group as they're redundant because of OnClick or G (SVG g element)), refactored (add generic parameters, for better generic inference), and/or generalized (e.g. Pointer which can now be used for all Elements, or Fill/Stroke which can also be used for raw SVG elements such as <circle> or <text>).

This kind of introduces the idea, that a fully-typed close(r) to the spec following HTML/DOM API can coexist with custom views/widgets (in this case kurbo shapes used as SVG basic shapes, previously in xilem_svg)

[richard-uk1]

I'm keen for this to happen - I will try to find time for review.

[raphlinus]

Extremely awesome! I was able to get my beztoy example ported over with minimal fuss, and I'm looking forward to being able to wire up HTML sliders (I haven't done this yet, but expect it to be straightforward).

The one snag I hit is that I had put a .fill(NONE) on a g to disable fills of all the paths in the group, but that no longer seems to be enabled. This was not hard to work around (just set that on each of the paths), but feels like it should work.

I haven't reviewed the code in detail (only checked to see whether it works) but based on a skim I don't have any major concerns. I could do a deeper review if that would be helpful.

[Philipp-M]

Thanks :)

Well, I guess I need to dig a little bit deeper what is allowed in SVG and what not (my experience with SVG is limited yet...). g seems to inherit all kinds attributes for its children etc. so I've added stroke and fill to the SvggElement interface/trait in the latest commit, such that they're now generally available on the g element. I haven't found NONE though, I guess Color::TRANSPARENT has the same effect though (and it should behave the same as fill in xilem_svg).

(And I renamed Cx::add_new_attribute_to_current_element -> Cx::add_attr_to_element and IntoAttributeValue::into_attribute_value -> IntoAttributeValue::into_attr_value since it's less verbose, I don't think that's worth its own PR...)

I feel rather confident about the code, so a deeper review may be helpful but I don't think it's really necessary.

[raphlinus]

I think this is ready to merge, as the latest change addresses my concern. Thanks!