Performance: parallel per-file type checking

[michaelglass]

Summary

Massive performance improvement to the linting pipeline, built on top of #845.

Runs ParseAndCheckProject and per-file ParseAndCheckFileInProject concurrently using Async.Parallel. The project check warms the FCS incremental builder; parallel per-file checks share the builder and benefit from its warmed state.

Also enables parallelReferenceResolution on FSharpChecker.Create.

Performance

Project	Before (sequential)	After (parallel)	Speedup
FSharpLint.Core (15 files)	15.4s	12.5s	~1.2x
my internal project (48 files, many huge reps)	658s	~25s	~25x

The speedup scales with file count — larger projects see dramatically larger gains.

Test plan

• Full test suite passes (1003 unit + 26 console + 13 functional)
• Verified identical warning count between sequential and parallel approaches
• Type-check-dependent rules (FL0065 hints, FL0085 tail call diagnostics, FL0095 sync naming) produce correct results in parallel mode

A note on this PR

This PR was developed with significant AI assistance. I understand if that's not welcome — apologies if so. Happy to discuss the changes or withdraw the PR.

🤖 Generated with Claude Code

[Numpsy]

Fwiw I was having a go at passing the project options down from the top in #845 which avoids some of this overhead and avoids a larger perf regression when using the .NET 10 version of FCS, not sure what the best approach is though.
( I also wondered if just passing the project name in directly and avoiding dependencies on the project options would simplify things, if that's the only property that's needed)

[michaelglass]

oh nice. Yeah I've been doing a deeper dive on fsharplint perf because on one of my projects, it takes 5 minutes to run.

[michaelglass]

going to rebase on your PR, I think that approach is better.

[knocte]

@michaelglass why did you close it? Sorry for being a bit MIA these past months, I dropped the ball.

[michaelglass]

sorry it's been a long time. I should have left a comment!

IIRC the bulk of the perf gain was actually #845.

in this comment I discuss other perf explorations I did. I can rerun benchmarks on this branch but I'm pretty sure I closed it because the benefit outside of 845 was overstated.