Throw dev mode exception when a keyed each has duplicate keys

[Conduitry]

Is your feature request related to a problem? Please describe.
Duplicate keys in a keyed each can cause confusing runtime errors.

Describe the solution you'd like
A dev-mode-only check for

Describe alternatives you've considered
Making keyed eaches behave better when there are duplicate keys sounds like a lot of work and probably not a good idea anyway.

The only alternative I've really considered (besides doing nothing) is to run this check all the time with keyed eaches, not just in dev mode. But this would be a) more code for people whose apps are already working fine, and b) more work for the browser to do. I think this makes the most sense as a dev mode error (or possibly a dev mode warning).

How important is this feature to you?
It'd be nice. It shouldn't be too hard (I have it basically working locally), and it doesn't introduce any extra cost to people in prod mode.

Additional context
See #4244.

[tanhauhau]

We use update_keyed_each helper function to update a keyed each logic blocks in Svelte.

The implementation of update_keyed_each can be seen here.

To add a dev-mode-only check for the update_keyed_each, you need to:

1. Implement update_keyed_each_dev. (the name is important, you need to suffix the runtime helper function with exactly _dev to be picked up by the Svelte compiler.)
2. You can add the update_keyed_each_dev in the src/runtime/internal/dev.ts file. You can read other dev-mode-only runtime helper function implemented there too!
3. for unit testing, it can refer to this test case.
   • set the compileOptions.dev = true, and make sure it warns appropriately.
4. PR 🎉

---

If it is the first time that you contribute to Svelte, follow these steps:

1. Write a comment here to let other possible contributors to know that you are working on this issue
2. Fork the repo
3. Run git clone https://github.com/<YOUR_USERNAME>/svelte.git && cd svelte
4. Run npm install
5. Wait ⏳
6. Run npm run dev (or npm run build whenever you change a file)
7. Add a test
8. Update the code!
9. npm run quicktest to run the test without rebuilding
10. Run git commit with a meaningful commit message
11. git push and open a PR 🎉

You can read our Contributing Guide to learn more.

[Conduitry]

It turned out that update_keyed_each wasn't the only place this needs to be checked, as that isn't called when the each block is initially created. I have a WIP on the branch here that mostly just needs a little tidying then is probably ready for a PR. I ended up actually not using update_keyed_each_dev in my branch at all. I guess I don't really have a strong opinion about the tidiest way to handle this.

[tanhauhau]

Saw your branch, looks good to me

[ghost]

Did you mean to remove the measure function from keyed_each?
Conduitry@d36370c?diff=unified#diff-b66813450a6494de578b19bf54ea4083

[Conduitry]

It's an unrelated change, but I did intend to remove it. It's not used anywhere (I'm not sure when it last was), and it seems unrelated to the other keyed each stuff in the file.

[selevt]

Also see #4234, which has the same root cause.