Static Plugin Initializer

[TheBrambleShark]

Currently, plugin initialization takes three steps:

1. Instantiate plugin (with new() constraint).
2. Initialize plugin
3. Execute plugin

This creates a bit of weird situation, where plugins must be instantiated before the service provider is built. This creates a bit of a catch 22 - the plugin may require assets from IServiceProvider, but these are not able to be injected, requiring us to inject a raw service provider into the starup function.

Instead, I would like to propose that a static plugin initializer be added to the IPlugin interface and the service provider parameter in InitializeAsync be removed.

/// <summary>
/// Configures services provided by the plugin in the application's service collection.
/// </summary>
/// <param name="serviceCollection">The service collection.</param>
/// <returns>The service collection, for chaining.</returns>
static abstract IServiceCollection ConfigureServices(IServiceCollection serviceCollection);

/// <summary>
/// Performs any post-registration initialization required by the plugin.
/// </summary>
/// </summary>
/// <param name="serviceProvider">The service provider.</param>
/// <param name="ct">The cancellation token for this operation.</param>
/// <returns>A result that may or may not have succeeded.</returns>
ValueTask<Result> InitializeAsync(CancellationToken ct = default);

The new plugin initialization step would look like this:

1. Initialize the plugin by calling the static ConfigureServices() method.
2. Register the plugin with the service provider.
3. Instantiate the plugin with the service provider, allowing for DI to provide resources and services.
4. Call InitializeAsync() to start up the plugin.

[TheBrambleShark]

For NetStandard targets, we can reflect the static method by name and execute it. It's not ideal, but it will allow us to continue to operate with this new model regardless of version.

[Nihlus]

I like it!

[TheBrambleShark]

@Nihlus Are we still interested in supporting NetStandard and Net6? If not I'll remove those targets with this change. It will also tell me if I'll need the minimal API solution present for legacy support.

[Nihlus]

I think we can drop those targets now. I had (and have) some strong convictions on the matter, but it's pretty clear it's time to leave those targets behind.