fix: various snippet fixes

[jasonlyu123]

#2444 #2417 #2425 #2385 (comment)

The snippet is now transformed into a function with the return type so that The default parameter type can be inferred:

const foo = (a: string, b = 1): ReturnType<import('svelte').Snippet> => {

}

Another solution I considered using is an IIFE function so the inferred type is still Snippet<[...]>. But seems like typescript almost always expanded the type in hover. And

const foo = (() => {
    const $$_func = (a: string, b = 1) => { }

    return __sveltets_2_any() as Snippet<Parameters<typeof $$_func>>;
})()

I went for the ReturnType because the hover is shorter and the code generation is slightly simpler but OK with both so I could also change it to IIFE.

Breaking change

Since it is now possible to type snippets with JSDoc I removed explicit any in the generated code while changing the generation. This is a breaking change for js components with type-check but we can also add the any back for parameter without a default.

Scoping issues

The var is changed to const because this result in a runtime error but Typescript give a green light if it's var.

<div>
    {#snippet hi2()} {/snippet}
</div>

{@render hi2()}

The generated const is now hoist to before the first non-snippet sibling for #2417. And for implicit props, it's still passed directly to the component so the type can be inferred but another variable is generated for #2425

const {foo} = $$_tnenopmoC0.$$prop_def

A limitation is that we'll have to map the definition/reference/rename back but we can probably do this in a separate issue. Not even sure if many people actually rewrite something like this.

[dummdidumm]

Nice!