fix: more fine-grained SvelteSet and SvelteMap

[7nik]

Closes #16961— aligns behavior on non-existing keys with $state({}).

I noticed, in SvelteMap, signals are created in set, though it'd be better to create them only on reads, but then this.#fully_trackable has to be set to false which isn't good. So, I guess it's fine to leave it as is.

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: f2fa845

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

[github-actions]

Playground

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

[7nik]

Also, I'm surprised that SvelteURLSearchParams isn't fine-grained at all. Do we want it?

[7nik]

After it done, I recalled that it wasn't done initially because it can cause memory leaks by keeping keys forever. WeakMap is slower ~1.5 times on object keys and 15 times on primitive keys, which is probably too much.
Creating something like createSubscriber is likely too complex.