Refactor configuration to take advantage of Options Pattern

Current .NET Core configuration utilizes a non-conventional pattern to load configuration values.

https://github.com/umbraco/Umbraco-CMS/blob/43efee9647ed8f2eaab3ec2b71d3dd3eb46b9017/src/Umbraco.Configuration/AspNetCoreConfigsFactory.cs

ASP.NET Core already has an established pattern to load options. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-3.1

There are several advantages to using this pattern.

1. It’s common convention. No surprises for future contributors.
2. It allows options monitoring and dynamic reloading when required.
3. It negates the requirement for each superfluous interface definition and implementation.

Binding a section becomes trivial.

services.Configure<MyOptions>(Configuration.GetSection(nameof(MyOptions)));

Consuming it equally so.

public class MyOptionsConsumer(IOptions<MyOptions> options)
{
    Guard.NotNull(options, nameof(options));

    this.options = options.Value;    
}

Unit testing again is trivial.

var myOptions = new MyOptions();
var myOptionsConsumer = new MyOptionsConsumer(Options.Create(myOptions));

[AndyButland]

Can we/should we close this now @bergmania? Seems that any further uses of IOptions will come in as and when new features are migrated, rather than being a separate task to add.

[bergmania]

We decide to allow the MS Config interfaces in Umbraco.Core. @AndyButland already started a draft PR. Good start, and we can continue on work.

I think we should make a netcore/config branch as the base branch for all these smaller config PRs, so we can merge these into netcore/netcore as one big PR, but review it as several smaller PRs.