Turbopack: Fix compound assignment expression evaluation

[hayes]

fixes #85474

Previously, the analyzer treated all assignment expressions the same way, evaluating them as their right-hand side value. This was incorrect for compound assignments (+=, -=, *=, |=, >>=, etc.), which compute a new value based on both the left and right operands.

This commit distinguishes between simple assignments (=) and compound assignments. Simple assignments continue to evaluate to the right-hand side, while compound assignments are now properly marked as unknown values with side effects.

Also adds tests for compound assignments in conditionals, covering bitshift operations (>>=, <<=, >>>=) and bitwise operations (|=, &=, ^=) with both numbers and bigints.

[codspeed-hq]

CodSpeed Performance Report

Merging #85478 will degrade performances by 7.28%

_{Comparing hayes:canary (f308f17) with canary (1db1762)¹}

Summary

❌ 1 regression
✅ 7 untouched
⏩ 12 skipped²

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
❌	Simulation	react-dom-client.development.js[full]	427.9 ms	461.5 ms	-7.28%

Footnotes

1. No successful run was found on hayes/compound-assignment (137dbec) during the generation of this report, so canary (1db1762) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 12 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[mischnic]

Thank you!

[bgw]

FYI, @hayes I merged this into a non-fork branch to work around a CI issue we ran into (apparently the branch name "canary" on your fork was causing one of our webhooks to bail out). Running CI and attempting to merge into canary from here: #85593