fix: Produce an error when $props.id() is used after an await

[adiguba]

See sveltejs/kit#14994

When $props.id() is used after an await, the compiler fails and throw an unexpected error :

can't access property "map", n(...).declarations is undefined
Exemple in REPL

In fact there is a conflict between the behavior of $.run() and the early initialization of $props.id().

I looked at the generated code, and I think several compiler modifications would be needed to handle that case... :/
But there is absolutely no advantage for declaring $props.id() after an await, so I think the best solution would be to display a more explicit message.

This PR patch the compiler to produce these error on $props.id() :

$props.id() can only be used at the top level of components as a variable declaration initializer, and before any await expression.

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.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

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

[changeset-bot]

🦋 Changeset detected

Latest commit: fdc1b83

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

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-17273-svelte.vercel.app/

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@17273

[Rich-Harris]

As far as I can tell it's actually fairly straightforward to deal with $props.id() after an await — we just need to exclude it from the 'blocker' logic that puts every statement after an await into a thunk inside run. Opened #17285 as an alternative — any reason not to go that way instead?

[adiguba]

Yes it's a better solution.
I initialy tried to do something like that, but I was unable to do it as easily...