Simplify dotTrace diagnoser, dedupe common code

[martinothamar]

Similar approach to #2549 for simplifying DotTraceDiagnoser.

Also deduped some code by creating a shared project (using <Compile Include="..." /> to avoid another package).
Pulled this code into JetBrains folder so that the projects are ordered next to eachother in file explorers.
Made sure to update build script and references to include the new folder.

Other options:

• Just not dedupe
• Keep the common code in one of the projects and just include from there
• ?

[timcassell]

Could you use shared project for this?

[martinothamar]

TIL, did not know that existed 😄

I wanted to test that out now but I'm not sure if it's possible to create that project type for me since I'm working on Linux atm. .NET SDK, Rider and VSCode C# DevKit all seem to be missing support for creating this project type.

Reading up on this issue: dotnet/sdk#2511
There seems to be some complaints about the UX of it, but that it is fully usable. Some people suggest Microsoft.Build.NoTargets, while the "official" recommendation seems to be using a folder + globbing includes? I thought having a plain folder to contain the files would make intellisense/tooling/IDE experience worse but testing that out now its completely fine and everything works as expected. So personally I think the plain folder approach seems to be nice enough and lightweight. I pushed a commit now to do that

I could try out shared projects, but I would have to hand-code it unless someone on a Windows PC could scaffold it for me. What do you think?

[timcassell]

Ah, I didn't realize that was legacy project type. I think just using the folder approach is good.

[timcassell]

This was public before. Is it ok to remove it from public API? @AndreyAkinshin

[martinothamar]

True, I forgot to mention that. I figured since it's not used by any configuration or anything it makes sense to not expose it? Users could have referenced it for some reason, but not because of any interaction with BenchmarkDotNet AFAICT.

If we keep it public I probably have to do something about the namespace, so that both packages don't expose the same type in the same namespace, unless that's not a big deal since we don't expect anyone to import BenchmarkDotNet.JetBrains regardless of which package is used?