Create a test project for bulk code fix benchmarking

[psfinaki]

It would be useful to have some kind of large project so that we can keep track of bulk code fix performance on it.

Originally posted by @T-Gro in #15663 (comment)

[T-Gro]

To be more precise: I suggest to have a benchmark when a PR decides to rewrite things and have it as an artefact belonging to that PR.

I do not think that such specialized benchmarks should be persisted as part of this repo.

[psfinaki]

I do think they should be part of the repo. Code fixes are on the top of our code and there are a lot of things that can make them slow. They have a layer of logic which can make a difference but I'd argue that some changes in the F# core are equally likely to make editor slow.

Automatic benchmarks also would just eliminate a lot of subjective conversation and save much time.

[T-Gro]

Oh, but in that case that's an orthogonal story - setting up automatic benchmarks on the appropriate engineering platform (e.g. VS performance tests for VS services in particular) has nothing to do with having yet another test project in this repo. The more so that measuring should be as close as possible to what the end user perceives, so that it can properly reveal problems such as thread exhaustion or main thread waits.

[psfinaki]

Well, whatever we agree on. As I say, I'd just prefer as much automation and as little conversation about this as possible, especially in PRs. We can put tests here, or elsewhere - this really should be a part of a broader story. I see the parallel with tracking the performance of renaming stuff, finding references and so on, but just made this task about code fixes in particular.

[0101]

If we do this, we should just test our code without VS, since we're going to move to LSP.