fix: better $inspect.trace() output

[Rich-Harris]

While reviewing #16060 I took a closer look at the $inspect.trace() code and found some odd stuff plus a few bugs. This PR tidies things up a bit:

• it adds some previously missing types, which revealed some broken code that was never running because it was inside an if (/* impossible condition */) block, which is now removed (even if the removed block did do what it purported to, I don't think it would be desirable)
• it removes the special handing around each blocks. I couldn't for the life of me figure out how to make this do anything useful, and no tests failed when I removed it. 🎵 If you like it then you shoulda put a test on it 🎵
• it prevents duplicate TracedAt stacks, which can happen when e.g. using $state.snapshot (which enumerates properties and then reads them, both of which cause a stack to be added)
• it only prints UpdatedAt stacks for dirty signals. it's weird to include this for things that haven't changed
• it prints the current value of each signal. As of fix: correctly highlight sources reassigned inside trace #14811 it prints the value at the start of the effect but that makes no sense to me at all — in the test case from that PR it misleadingly appears that the value of count changed from start to end during the effect's final run, and if you add a derived, the logged values are inconsistent. It's simpler, both from the user's perspective and in terms of implementation, to just always show the latest value
• general tidy up

There's probably more that can be done to improve this stuff — for example I think we should show updated signals first, and relegate unchanged ones to the bottom, and the 'version' signals could probably have a clearer label. But I thought that could wait for a follow-up

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: 281b972

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-16131-svelte.vercel.app/

[github-actions]

Playground

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

[dummdidumm]

The debug field is necessary in each block cases like this:

• prod shows the correct stack back to the source
• this PR ends up in generated code, making the stack useless

It's because the each block creates signals for each array entry if it needs to.

Somehow it gets weirder when using $state as now every part of the entry is logged for some reason

[Rich-Harris]

alright, that should be fixed now