More robust handling of {@html ...}

[Rich-Harris]

Started working on this but just going to leave a failing test here for now. Basically, too much is happening during mount — when something is remounted (i.e. after a list shuffle) new DOM is created. We probably need an abstraction for handling fragments generated from HTML.

[Rich-Harris]

Significantly simplifies the code for {@html ...} tags by adding an HtmlTag class that does the heavy lifting. This class keeps track of the nodes it generates, so that it can efficiently detach them without needing to surround the tag with anchors. In the occasional situations where an anchor is necessary (because the following item isn't a DOM node), we can now use an empty string instead of ugly <noscript> elements, since it no longer uses the insertAdjacentHTML API.

Where possible (e.g. <div>{@html stuff}</div>), it will continue to use the innerHTML optimisation.

I haven't checked yet, but I'm optimistic that it will also fix #3326.

[Rich-Harris]

Confirmed this fixes #3326 — added a test

[sanderhahn]

Maybe these changes also fix #2711?

[Conduitry]

Oh nice, yeah it looks like it fixes that as well.

[Conduitry]

Actually, the REPLs in the first and third comments in the issue seem fixed with this PR. The second REPL still has something weird going on.

[Rich-Harris]

nice, another one down. The remaining bug in #2711 that wasn't fixed by this PR is fixed in #3350