Revert "Add support for user-supplied project file detection"

[adamsitnik]

This PR Reverts #2684

I appreciate the contribution, but the design is overcomplicated. I have done similar things in the past, but have learned from mistakes (the hard way). I believe thaat we should put more effort into introducing new public API and ideally follow rules described in Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .Net Libraries book.

It introduced a new interface (with a single method), a class (to represent two arguments) and an enum (with a single value). All of that could have been just a lambda. Example: Func<BenchmarkCase, ILogger, FileInfo?>. I know that it was done for the sake of extensibility, but it's a niche feature request and we simply don't need that.

It introduced the ability to customize a project file path outside of a toolchain, which so far was always responsible for that (via virtual method). At the same time, it introduced a possibility to specify multiple locators with no clear separation of which is used for given toolchain.

I believe that this responsibility should stay within the toolchains. Generators to be exact. And if we want to make it customizable, we should allow for providing the path via command line arguments.

cc @timcassell

[timcassell]

Sounds fine to me. It could also be passed as a parameter in NetCoreAppSettings.

cc @Genbox If you want to take another stab at it taking @adamsitnik's comments into account.

[miniksa]

Darn. I came by to use this functionality and it's been removed. :(

[miniksa]

Aha if you're here like I was, then doing .WithToolchain(InProcessEmitToolchain.Instance) resolves this inside your class inheriting from ManualConfig that you registered with the test assembly per https://benchmarkdotnet.org/articles/features/vstest.html

e.g.

AddJob(Job.Dry.WithToolchain(InProcessEmitToolchain.Instance));