chore: simpler <svelte:element> hydration

[Rich-Harris]

Occurred to me that we can apply the ideas in #11770 piecemeal with the current approach to hydration and still see benefits.

This makes <svelte:element> more efficient — in SSR, it skips the opening hydration marker:

-<!--[--><div><!--[-->...<!--]--></div><!--]-->
+<div>...<!----></div><!---->

As such, hydrate_anchor no longer needs to traverse the parent element just to populate hydrate_nodes with a single element whose identity we already know. We do still need to keep a closing anchor, to handle this going from falsy back to truthy.

TODO:

• remove the opening marker from inside the element, since it's really not needed.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 4831a8e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dummdidumm]

There's #10997 which is the more general issue about this - is this something we can apply more broadly in here aswell, or is svelte:element kinda special here and should be handled separately?

[Rich-Harris]

I suspect the patterns will apply broadly, but there'll be enough finicky details in the implementation that it'll be a piecemeal process. Case in point — I'm working on CSS custom property wrappers as part of this PR as well, and it's proving finicky because we currently implement them in a backwards way