Problem/Motivation
As per reviews by @webchick and discussion between @alexpott, @xjm and @effulgentsia, it may be a problem that configuration forms work totally opposite in terms of overridden values compared to how they worked in Drupal 7 and before. In Drupal 7 if you had a settings.php configuration override for example, that got used to build the configuration form and whatever you changed, the change did not stick. That was a WTF, but at least it was some sort of feedback on the value not being possible to change. In Drupal 8 however, overrides are not used to build forms and you can actually change settings and they would actually be saved and then displayed again on the form as if they were persisted. They are actually persisted but overrides may still apply on them, so the operation may be moot.
Proposed resolution
Following #2392319: Config objects (but not config entities) should by default be immutable each configuration form knows about the configuration keys edited and centralizes an accessor ($this->config()) to access them. Thanks to this, we can track if there were any configuration details loaded that may have overrides applied (by loading the editable version as well and comparing the data). That way, we can detect if there are overridden values at least under the same conditions as the admin form was displayed (eg. static global overrides). Using that information, we can display a message on top of the form if there is overridden configuration and editing is pointless.
Remaining tasks
Implement. Add tests. Review. Commit.
User interface changes
Configuration forms may display a message on the top if there are overridden values.
API changes
None.