xilem_web: Optimize modifiers (allocs mostly), and fix hydrating SVG elements

[Philipp-M]

With the risk of wasting time with micro-optimizations...

Honestly the diff bigger and more complex than I would like it to be for the effect that this change does, so I'm sorry to reviewers.
FWIW, I tested all the examples with the feature "hydration" disabled and enabled.

In effect this reduces the amount of allocs and the size of allocs of all the modifiers (since Vec allocs at least 4 elements) by:

• Adding a size hint in modifier views, to give the actual element props a hint how much memory is needed in the relevant modifier, so that only one allocation occurs when the actual modifier is added/created.
• Using bitflags encoded in the start_idx to avoid extra 4 bytes for just two booleans in each modifier, and also use u16 instead of usize to save another 4 bytes.
• Avoiding updated_modifiers allocations when building the element (with the CREATING bitflag).
• Reduce allocations when rebuilding, by skipping non-changed modifiers (before this, Cow was cloned, which for example with a String as an attribute value resulted in an additional allocation).

This minimally increases the wasm binary size (though I'm pretty sure in a constant fashion, roughly 500bytes compressed) in exchange for faster creation of elements and less memory usage (in the 10k js-framework-bench roughly 10% less memory usage, and 7-8% faster).

I've also noticed that all the kurbo SVG views weren't hydrated yet, which I think results in buggy behavior when using it e.g. in a Templated view, this is kind of drive-by fix (which I didn't want to separate because of additional work...)

[flosse]

I have to admit that I didn't understand all of the content, but at least I didn't notice any obvious mistakes.

[Philipp-M]

Thanks, yeah it's probably not straight-forward, I hope to simplify parts of that in a future PR though, maybe even generalize this (or another) kind of modifier-system (maybe even in xilem_core), as I noticed that xilem native could also benefit from it (see also #591 (comment)).