Configuration hierarchical composability

[JanKrivanek]

Context

Analogy to Roslyn globalconfigs asked by couple users during initial demos.
Being able to set 'policies' centrally via package is currently missing.

Possible goals

• Being able to set different (additive) configs on different levels (e.g. rule with whitelist allows additive configuration of whitelist, insted hiding the higher level setting)
• Unlocks ability to ship default configurations

Example of usage

• A theoretical buildcheck ForbidSettingUnderscoreProperty, that will flag assigning to the property starting with underscore
• The buildcheck will have a whitelist setting (settable via .editorconfig) to allow exceptions
• Someone would like to set a whitelist for the check on the scope of whole repository in the root of the repo with .editorconfig:

microsoft.buildcheck.AB1234.whitelist=_propA,_propB

• We then would want to add additional whitelist for a subsection of repo (or a specific project), but without overwriting the higher scope settings. So e.g.:

microsoft.buildcheck.AB1234.whitelist=_propC

would allow the whitelists to be joined

The actual implementation and exposing would need to be designed and thought through (e.g. should the additivity be explicitly opt-ed in in the .editorconfig, the Checks might then receive enumeration of setting per single key)

The additional scenario that this then unlocks is: "Can we create and distribute .editorconfig file via nuget packages, so that users can apply it and get preconfigured behavior as a base for their build" - this is not possible today, as only .editorconfig files in the code hierarchy are being recognized (obj and nuget cache are ignored). This would need design as well (what is the priority, opt-in/out, etc.)