feat(core): add experimental performance report

[lo1tuma]

Adds an opt-in, experimental performance report to help diagnose and compare mutation-testing performance. This is the groundwork for measuring the static-mutant performance work discussed in #6135.

Enable it with experimentalPerformanceReport: true, and Stryker writes reports/mutation/performance.json alongside the normal reports. It captures per-phase timing (setup, initial run, mutation, reporting), the static-vs-runtime cost split, environment reloads and reload time, per-worker utilization, retry/out-of-memory counts, and machine and configuration info. The standard mutation.json and HTML report are untouched, and there is no behavior change unless the option is set.

The format is intentionally experimental and unstable: the idea is to try it as a dedicated, opt-in channel first and, if it proves useful, consider promoting parts of it into the standard report later. docs/performance-report.md documents every field and, importantly, how to read the numbers: wall-clock phases (which sum to the total) versus work summed across parallel workers.

I ran this on a large real-world mocha + TypeScript project (~5500 mutants). Beyond the well-known #3282 pattern (static mutants are a small fraction of the count but a large fraction of the cost), the metrics surfaced things that weren't visible before: reloadEnvironmentLast doesn't order static plans globally, so static and runtime work interleaves and each interleaving triggers an extra full-restart reload on the following runtime mutant. That adds up to hundreds of avoidable reloads, which is why totals.reload reports more reloads than there are static mutants. Pure environment reload accounted for ~23% of static-mutant time, and ~45% of mutants were killed as CompileError by the type checker before ever reaching the test runner.

Closes #6135