come up with a design for config containers

**What I'd like:**
Quite a few issues - #2218, #1702, and many others - would ideally have a way to be quickly unblocked by targeted config file edits until the requested functionality could be integrated in the settings API. Currently this is strongly discouraged, albeit possible in limited ways through containers with the `super_t` label.

There are a few major concerns that motivate this limitation:
* settings can be changed via API at any time, clobbering any unexpected edits to the config file
* config files might move around across an update, breaking expectations on where to make the edit
* modifying certain config files could impact the security of the system

Any solution will need to address these concerns in some way.

**Any alternatives you've considered:**
Keep the status quo.