Implement a perf testing benchmarking system

[markerikson]

Per #1152 , I've been investigating Immer performance across versions.

I originally wrote a perf benchmarking setup in https://github.com/markerikson/immer-perf-tests . Since then, I've iterated on it significantly - adding support for CPU profiles, sourcemappings, and logging more details.

This PR ports the benchmarking setup to be a subfolder directly integrated into the Immer repo, which should make running benchmarks straightforward - just yarn build-and-profile in the ./perf-testing folder to both rebuild the current Immer source and the benchmarking script, then run it with per-version-per-use-case relative comparisons and a generated CPU profile.

As with #1162, the work for this PR includes a lot of AI-generated code from Claude. This is a relatively new experiment for me, and I've done a lot of careful babysitting to keep it going in the right direction and tried to review and check the results.

Changes for the benchmarking setup in this PR:

• uses Rolldown for fast building of the benchmark script with all the different Immer versions
• Bundling the benchmark and the Immer versions ensures that we're using the production builds of each version, and also that we avoid expensive process.env.NODE_ENV checks while running the benchmarks (which is what caused earlier versions of my benchmark to seem slower, as they were directly running the immer.mjs artifacts in Node)
• The benchmarking script uses the https://github.com/evanwashere/mitata benchmarking library to get fine-grained timings for how each Immer version performs across different use cases and settings (add/update/remove/concat/filter, freeze / no freeze), and compare the relative speed of each version
  • the script can run Immer 5 through 10 and the current "10Perf" version. Commenting out the version in the immerProducers object controls which versions actually get run in the benchmark
  • I added a new setUseStrictIteration option in my upcoming perf optimizations branch. The script currently has logic set up to be able to call setUseStrictIteration(false), but has the import of that function disabled until it's used with the perf optimizations branch to avoid "this import doesn't exist" errors
• Running that same benchmark script with --cpu-prof generates a .cpuprofile file that can be analyzed with read-cpuprofile.js
• read-cpuprofile.js uses sourcemaps for each library to properly identify functions and associated perf samples, and then logs information on the most expensive functions for each version

[coveralls]

Pull Request Test Coverage Report for Build 17538736762

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.795%

---

Totals
Change from base Build 17384759936:	0.0%
Covered Lines:	649
Relevant Lines:	650

---

💛 - Coveralls

[mweststrate]

Ok, this is super cool. THanks for bringing the state of the art!

[github-actions]

🎉 This PR is included in version 10.2.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀