Configuration hierarchical composability

### Context

Analogy to Roslyn `globalconfig`s 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:
```ini
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.:
```ini
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.)

Start by reviewing how .editorconfig files are recognized in the code hierarchy, including the stated exclusions for obj and the NuGet cache. Define the precedence, additivity, and opt-in or opt-out behavior for hierarchical settings and packaged configurations; done means those rules and the implementation scope are agreed.

Written by the indexing model from the issue text.