Revisit by-convention options from configuration

[divega]

@Eilon has expressed some concerns with the "amount of magic" in the current design that pulls configuration information into an instance of an options type MyOptions through a call to services.Configure<MyOptions>(configuration), and on how this is currently used across the frameworks. Filing this issue to track that so that we can have a follow up conversation.

[HaoK]

Related to this, currently all of the frameworks are implicitly expecting their options to live at top level, we need to change the behavior of all the frameworks AddFooXXX(Configuration) method to implicitly be looking for Configuration.GetSubKey("FooXXX") or pick some other naming convention to properly scope the options.

[HaoK]

This is currently broken again, along with service replacement due to frameworks calling Add on their dependencies, i.e. Options, DataProtection, etc.

[HaoK]

@davidfowl suggested that we just cut all automatic Configure options from any AddXyz methods, users can always manually call services.ConfigureXyz(config) to bind options to config. I will make a pass once builds are stable and remove Configuration from all AddXyz methods that do not need them

[HaoK]

Removed Configuration/Automatic ConfigureOptions using config from AddXyz methods