Feature request: Make MAX_CONCURRENT_INIT configurable

## Summary The `MAX_CONCURRENT_INIT` constant in `packages/core/src/concurrent/pool.ts` is hardcoded to `2`, which limits worker process initialization to 2 concurrent processes at a time. On machines with many cores and sufficient RAM, this creates an unnecessary delay during startup. ## Current Behavior With `concurrency: 12` configured, initializing 12 test runner workers takes ~21 seconds on a large project because they're initialized in batches of 2: - 12 workers ÷ 2 concurrent = 6 sequential batches ### Before (MAX_CONCURRENT_INIT = 2) ``` 00:48:49 INFO ProjectReader Found 128 of 4210 file(s) to be mutated with 8749 mutant(s), and 3945 test(s). 00:48:49 INFO Instrumenter Instrumented 128 source file(s) with 8748 mutant(s) 00:48:50 INFO ConcurrencyTokenProvider Creating 12 checker process(es) and 12 test runner process(es). 00:49:11 INFO DryRunExecutor Starting initial test run... ``` **21 seconds** to initialize workers. ### After (MAX_CONCURRENT_INIT = 12) ``` 00:59:32 INFO ProjectReader Found 128 of 4210 file(s) to be mutated with 8748 mutant(s), and 3938 test(s). 00:59:32 INFO Instrumenter Instrumented 128 source file(s) with 8748 mutant(s) 00:59:33 INFO ConcurrencyTokenProvider Creating 12 checker process(es) and 12 test runner process(es). 00:59:40 INFO DryRunExecutor Starting initial test run... ``` **7 seconds** to initialize workers — a **67% improvement**. ## Requested Feature Add a configuration option (e.g., `maxConcurrentWorkerInit`) to `stryker.conf.mjs` that allows users to tune this value based on their hardware. ```js // stryker.conf.mjs export default { concurrency: 12, maxConcurrentWorkerInit: 6, // or even 12 for beefy machines // ... } ``` ## Test Environment - 12-core CPU, 128GB RAM - Large project: 4210 files, 8748 mutants, ~3940 tests - Tested by patching `dist/src/concurrent/pool.js` directly ## Why This Matters - Modern development machines often have 8-16+ cores with plenty of RAM - The conservative default of 2 was likely chosen for CI environments with limited resources - Making it configurable allows users to optimize for their specific hardware without affecting the safe default - On larger projects, the initialization overhead becomes significant ## Backward Compatibility The default would remain `2` (or whatever is currently considered safe), so existing behavior is unchanged unless users explicitly configure a higher value.