Problem/Motivation
Unless a config entity always uses or subclasses ConfigEntityStorage, there is no way to be sure that it supports overrides, dependency management, scalable entity queries, etc.
Proposed resolution
Enforce tight coupling between ConfigEntities and ConfigEntityStorage
Remove KeyValueConfigEntityStorage and associated tests
Remaining tasks
User interface changes
API changes
Trying to use a storage class that does not extend ConfigEntityStorage will now throw a ConfigEntityStorageClassException exception.
Original summary
Content and config entity info is currently collected at the same time, and also has the same _alter() hook.
Configuration entities have a locked storage backend (must always be configuration storage, you can't swap it to something else and expect it to work). There's also going to be more divergence down the line.
So we should split the discovery and the alter to make it clear these are different things, and enforce the storage restriction on the configuration entities.
This would also solve issues like #1801304-195: Add Entity reference field where there's no differentiation between the two.