[D8][PS] Make config storage swappable

There is one storage class available for Config to use: ConfigFileStorage. I'd like the option of using a ConfigDatabaseStorage class that would save the same data, but in the database instead of in flat files.

I can think of the following reasons why: - Makes it easier to synchronize config changes among multiple web servers in a load balanced environment. - Makes it easier to capture the entire state of an environment for debugging elsewhere.

Summary:

This is a feature request for an option that will likely only be used by a minority of sites running Backdrop. As you can see in the discussion below, there are other reasons it might still be a candidate for core inclusion. This option would be disabled by default, so there would be no change for existing sites, or new installs.

Here is a list of pros and cons for PMC review:

Pros * some load-balanced sites may choose use this setting. * similarity to Drupal 8 / Drupal 7 / WordPress (w/ config in db) * one less data source for devs to download. * discourages manual editing of the active configuration (security by obscurity). * Hosting platforms that were built for config-in-db projects could be used in the way they were intended (config + content together) * possible performance gain for the minority when feature IS in use (needs benchmarks) * Security improvement: databases tend to be behind firewalls and only accessible by the webheads, which protects configuration better than an easily misconfigured web server directive protecting one directory in an otherwise published files directory. * It's very hard to add this kind of feature in contrib.

Cons: * does not benefit at least 80% of sites using Backdrop. * increased complexity / more code to support (slightly). * database-storage is less visible than files, making Backdrop harder to learn. * Hosting platforms that were built for config-in-db projects would no longer benefit from the separation of config and content * possible performance impact on the majority when feature is NOT in use (needs benchmarks) * possible performance impact on the minority when feature IS in use (needs benchmarks) * We would need to do all automated tests w/ both file and db configs to avoid any possible exceptions.