Make reqnroll around builder pattern

[Romfos]

I think that there are a lot of good suggestions in this #472 discussion.
My proposition is to follow app builder pattern that you can see in aspnet like that:

public static class Program
{
    public static async Task Main(string[] args)
    {
        var builder = new SpecflowApplicationBuilder();

        builder.Configuration.UseStandardReqnrollJsonConfiguration();
        builder.UnitTestsPlatform.UseMsTestAdapter();
        builder.Logging.UseDefaulLogger();
        builder.Services.AddSingleton<IMyCustomService>();

        builder.UseCustomPluginFromExternalLibrary();

        builder.Features.AddFeaturesFromExecutingAssembly();
        builder.StepsDefinitions.AddStepsFromExecutingAssembly();

        var specflowApplication = builder.Build();

        await specflowApplication.RunAsync();
    }
}

potential builder:

public sealed class SpecflowApplicationBuilder
{
    public SpecflowConfigurationBuilder Configuration { get; } = new();
    public UnitTestsPlatformBuilder UnitTestsPlatform { get; } = new();
    public SpecflowLoggingBuilder Logging { get; } = new();
    ...
    SpecflowApplication Build();
}

public sealed class SpecflowApplication
{
    Task RunAsync();
}

Rules:

1. Static classes\methods\properties\e.t.c are banned (maybe marked as deprecated on the first version). You can override any services via di and public interface
2. Extension via DI container and extension methods to this builder like builder.UseCustomPluginFromExternalLibrary(arg1, arg2)
3. No magic like automatic assembly scanning, e.t.c. For extensibility should be syntax that use should explicitly call like:

builder.Scenarios.AddScenariosFromExecutingtAssembly();
builder.CustomStepTranformations.Add<MyCustomStepTransformation>();

as the result you have only what you specified in builder => faster startup & run without not needed services. You should check your build and be sure that exactly you are using and where

4. Code first approach. Now you need to google all settings names. Would be better to get them from intellisense.
   You can still use json config via:

builder.Configuration.UseStandardReqnrollJsonConfiguration();

but it should be optional way as any other config provider. The same for Logger, e.t.c. Maybe these should be remove from "core" library and provided as external library for those who needed it

5. App should have minimal amount and reasonable defaults

var builder = new SpecflowApplciationBuilder();
builder.Scenarios.AddScenariosFromExecutingtAssembly();
await builder.Build().RunAsync();

should work and work really fast

My private opition about reqnroll design in general:

I think that for years specflow & reqnroll get tons of "features" that I really never (or rare) use like custom json parsers\custom di\multiable adapters for tests\step args transformations\plugin system\feature+scenario contexts\report generators\source generators\cucumer messages\e.t.c. Tons of them!!

From my point of view would be better to split (or reimplement) it like

1. Reqnroll nuget that allow just run scerarios and support step definition
2. Reqnroll.SpecflowCompatibility nuget . Plugin that "returns all shit back"
3. Reqnroll.Configuration.ReqnrollJson nuget. Extends to load config from reqnroll.json. only for those who need it
4. Reqnroll.ExcelDataPlugin nuget. That add support for excel data source. again, only for those who need it
   e.t.c

Features that should be out of the box:

1. App builder
2. Default DI abstraction
3. Default logging abstraction (default console output)
4. Default configuration abstraction (via code only, no default providers from external sources)
5. Ability to register feature files
6. Ability to register step definition classes
7. Maybe hooks pipeline?? (like BeforeScenario)
8. List of public interfaces that plugins could implement and register in DI to provide extra features
   That's it!

As the result it should be small\easy to support\fast to run library