fix: CSS adjacent and general sibling combinator treats slots as if they don't exist

[ngtr6788]

Fixes #8284.

The problem is that the <slot> element is treated as an actual element, and for this purpose, we have to treat them as if they don't exist. More specifically, we treat all slot fallback children nodes on the same level as the slot's non-slot siblings.

[edit: I wasn't aware of the <slot> element in web components before, so I added a check that if the node belongs to a web component, we still treat slots as if they exist.]

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

• Run the tests with npm test and lint the project with npm run lint

[vercel]

@ngtr6788 is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

[dummdidumm]

I'm not 100% sure if we want to always do this. In the case of custom elements this element actually exists.

[ngtr6788]

Interesting! I am not aware of nor am familiar with web components before. Do you know what the expected behaviour would be? For example, from the bug report,

<h1>test</h1>
<slot><span>Hello</span></slot>

<svelte:options tag="my-element" />

<style>
  h1 + span {
    color: red;
  }
</style>

does h1 + span pick up the Hello, if this were a custom component?

[EDIT:]
To answer my own question, the answer is no. However, in a custom web component, h1 + slot > span does pick up the default (ie. <span>Hello</span>). Sorry for asking