Add support for named options

[HaoK]

        SetupNamedOption("ApplicationCookie", options => { })
        UseCookieAuthentication("ApplicationCookie")
        SetupNamedOption("ExternalCookie", options => { })
        UseCookieAuthentication("ApplicationCookie")

        // Overloads which use default/no name
        SetupOption(options => { })
        UseGoogleAuthentication()

Add Name/GetNamedOptions to IOptionsSetup/OptionsAccessor

[lodejard]

Also the

    public interface IOptionsConfiguration<in TOptions>
    {
        int Order { get; }
        void Setup(TOptions options);
    }

should probably take void Setup(string name, TOptions options); - I recall we talked about adding a property string Name, but it would be more flexible to let the component decide if the name applies or not

[HaoK]

@lodejard If we didn't have a Name property on the IOptionsConfiguration, how would we filter based on Name before applying them? Is the idea that instead that the default OptionsConfiguration class would take the targetName in the constructor and only execute the action if the name matches during setup?

[lodejard]

Yep

[HaoK]

Updated the PR with the change to take names in Setup, can you review? #15

[divega]

We ended up using a property for Name and not having the name argument from the method that applies the Action. This is the simplest design that allows deterministically executing unnamed options before matching named options for the same Order. We are keeping this item open so that we can reconsider this later, e.g. if we still believe that it is compelling to build more flexibility into the name matching logic, we should also consider providing a way to compare two instances of IOptionAction in order to sort them correctly, e.g. we could have IOptionAction implement IComparer and then OrderBy(s => s) should pick it up automatically.

[HaoK]

#21