feat: improve duplicate key error for keyed each blocks

[rafistrauss]

Closes #8410

Adds the duplicate key in the error message, to allow for easier debugging.

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.

Tests

• Run the tests with npm test and lint the project with npm run lint

Note
Lint passed, I ran npm test but saw the following 2 failures which I can't imagine were caused by my change:

[vercel]

@rafistrauss is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

[Prinzhorn]

Since keys can be anything this should probably use something similar to util.inspect to stringify the key into a human friendly version (maybe Svelte already has a primitive for this job, I'm not familiar). E.g. for Symbols your code will crash with:

Uncaught TypeError: Cannot convert a Symbol value to a string

[tanhauhau]

wrap around with quotes to have a clearer idea of when the key starts and ends, especially when having string value as key.

Also, i would suggest add JSON.stringify() to differentiate between number and string value key

Suggested change

	throw new Error(`Cannot have duplicate keys in a keyed each: ${key} is a duplicate`);
	throw new Error(`Cannot have duplicate keys in a keyed each: \`${JSON.stringify(key)}\` is a duplicate`);

[gtm-nayan]

For the problem that Prinzhorn mentioned, maybe using String() before inlining the key into the template string could be a workaround. For Symbols at least, I found that String(Symbol()) returns the string Symbol() instead of throwing that error.

[dummdidumm]

Instead of trying to find a good stringified representation, I suggest to instead print out the index of the duplicates.

[rafistrauss]

Instead of trying to find a good stringified representation, I suggest to instead print out the index of the duplicates.

Why not both? The string itself is much easier if your data is being reordered or transformed, so having that is the primary benefit in my mind. Then, if that approach fails due to the issues raised, provide the index as a fallback