Problem/Motivation
Views collects dependencies for a view in all sorts of ways, eg. handlers used under displays. Unfortunately the module providing the display itself is not added as a dependency, although it may very well be an optional module. Eg. user module provides two views that have block displays. The block display cannot be validated as configuration unless the block module is enabled. The display then is merely "optional" or in other words plain broken.
Found this in #2183983: Be stricter about schema issues once a config has schema.
Proposed resolution
1. Make the view inherit the provider of displays as dependencies of the view config entity.
2. Add missing provider info on block, rest and entity_reference displays in shipped config. There are two other displays in tests, but those are not referenced in shipped config.
The resolution itself will not fix the dependency problem as configuration is still imported even if internal dependencies are not met. The configuration system requires that configuration is in containing modules that are themselves dependent on all modules that their configuration depends on. That means the crucial node, user and comment module views affected in this patch will *also* need to move to a place where block module is enabled (naturally to standard profile). That will be in #2309715: Node, comment and user modules have views that also depend on block, move to standard profile.
Remaining tasks
Reviews. Commit.
User interface changes
None.
API changes
None.