Don't rely on IoC containters to preserve registration order IConfigureOptions services

[halter73]

Autofac and possibly other IoC containers will not return IEnumerable resolved services in the order they were registered, but Options currently depends on this behavior. This causes certain extension methods in Kestrel, WebListener, MVC (and EF?) to break when Autofac is used.

This will probably require adding an Order property back to IConfigureOptions similar to what we had back in beta7.

A key difference is we want to continue running the actions passed to Configure in the order they are added. This will likely require that Configure inspect the IServiceCollection prior to registering the ConfigureOptions instance.

This should resolve the issues raised in aspnet/Hosting#785

[divega]

A few more details:

1. We should bring back the overloads of Configure<T>() that allow setting the order.
2. When Configure<T>() inspects the service collection for existing instances of IConfigureOptions<T> we should do (pseudo code):

Order = 1; 
if (setups.Any())
{
   Order+= setups.Max(s => s.Order);
}

. This works better for custom order than other alternatives. 3. This will be a breaking change for any custom implementation ofIConfigureOptions`, including our own in https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Core/Internal/MvcCoreMvcOptionsSetup.cs and https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.WebApiCompatShim/WebApiCompatShimOptionsSetup.cs.

[HaoK]

We decided we are going to require IoC containters to preserve registration order