Consider switching to IConfigureOptions instead of ConfigureOptions in OptionsSetup

[pranavkm]

The API for using IConfigureOptions<> is a bit more traditional than using the lambda overload that ConfigureOptions<> has:

Consider what we have

public class MvcCoreRouteOptionsSetup : ConfigureOptions<RouteOptions>
{
    public MvcCoreRouteOptionsSetup()
        : base(ConfigureRouting)
    {
    }

    public static void ConfigureRouting(RouteOptions options)
    {
        options.ConstraintMap.Add("exists", typeof(KnownRouteValueConstraint));
    }
}

versus

public class MvcCoreRouteOptionsSetup : IConfigureOptions<RouteOptions>
{
    public void Configure(RouteOptions options)
    {
        options.ConstraintMap.Add("exists", typeof(KnownRouteValueConstraint));
    }
}

[rynowak]

FYI , I asked @pranavkm to file this, it's just code cleanup. The ConfigureOptions base class is kludgy to use when you have constructor parameters

[Eilon]

The type MvcCoreRouteOptionsSetup is in a .Internal namespace. Can we clean this up later?

[rynowak]

We can do this like 10 years from now 😆

[Eilon]

Got it.