chore: configure knip

[Rich-Harris]

As @dominikg pointed out recently, it's a bit weird to include knip config in the package.json that gets included in the svelte package.

This PR moves it into a separate knip.json file, beefs up the configuration to cut down on some of the noise, and acts on some of its recommendations (yes, this includes installing certain workspace-wide dependencies inside package/svelte; an alternative would be to move the knip config into the root).

With this change, the only warnings that are left are ones that appear to be legitimate:

> [email protected] knip /Users/rich/Development/SVELTE/svelte/packages/svelte
> pnpm dlx knip

Unused exports (6)
svelte_fragment_invalid_slot           e  function  src/compiler/errors.js:1254:17            
Parser                                    class     src/compiler/phases/1-parse/index.js:17:14
a11y_incorrect_aria_attribute_type_id  w  function  src/compiler/warnings.js:244:17           
derived_iife                           w  function  src/compiler/warnings.js:581:17           
ELEMENTS_WITHOUT_TEXT                     unknown   src/constants.js:56:14                    
svelte_component_invalid_this_value    e  function  src/internal/client/errors.js:349:17

Ultimately I'd like to run knip in CI, but that can happen separately.

[changeset-bot]

⚠️ No Changeset found

Latest commit: edd9dc8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[dominikg]

this is probably the bigger change than moving the knip config. but i guess its fine because svelte itself does not consume libs in a way we would gain something from these checks?

[Rich-Harris]

yeah, I'm seeing some annoying errors due to some type changes in a dependency that are totally irrelevant to us and to Svelte consumers. I don't see much value in checking libs

[dummdidumm]

We can't really do this, we won't be able to catch errors in our own d.ts files from now on. The alternative is to turn all our d.ts files into ts files which will be type checked