Implement automated and granular CMI snapshots to back up files when a module is uninstalled

Problem/Motivation

TL;DR: we cannot assume that everybody's going to leverage version control to handle CMI file changes. But what we know for sure is that every D8 user will at some point need to 'disable' (uninstall) a module without losing the associated configuration.

Per #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed modules can no longer be disabled. #2035079: [PP-3] Figure out what to do with the install/uninstall modules page is going to handle the UX for site builders to better understand how to deal with the missing 'disable' state. We're however left in a state in which site builders will not necessarily know how to not lose their configuration data if/when they need to uninstall a module for any given reason (e.g. custom module is breaking the site)

In core we can:

• Leverage the single export feature => Very easy to understand for site builders (/admin/config/development/configuration/single/export) but what happens when you have, say, 5+ config files to manually back up? What if you miss one and can't import successfully next (e.g. field storage dependency)? Even more tricky, what if only part of the configuration is being imported and breaks the site's functionality but nobody immediately sees it? There *is* an alternative if you leverage the Features module, but it's targeted at advanced users.
• Leverage the full export feature => works as above except we basically snapshot the full conf and download a tar.gz archive locally that we can later import on the site. Would prevent issues with the simple export/import but it's not super flexible. E.g. in a distributed team (say, UK and Australia) what happens when John (Australia) implements 10s of changes for several configuration files via the GUI, then manually backs up the conf locally to uninstall a bunch of modules, then Bob (UK) takes over the development for the day and needs the original backup that only John has? John is not around for the rest of the day and the team is stuck or needs to find alternatives (restoring from backup? recreating the configuration? etc.) but there's no way to have the latest and greatest archive that John has.

We could also leverage a contrib module (maybe improve disabled_modules?) to automatically back up config files when a module is disabled => would work as the below proposal, but would also mean you'd have to have the module available in the codebase/installed before being able to rely on any of those frequent activities.

Proposed resolution

Implement automated and granular CMI snapshots to back up files when a module is uninstalled => in essence, this could be as simple as dumping the specific config files to /tmp when a module is uninstalled. Or, we could ideally make this a customizable path for customers to set where to back up CMI files (e.g. under files/*). In other words, the workflow would be such as each time you'd uninstall a module, its config file(s) would be backed up automatically behind the scenes in a given location, for future potential re-use. Could be with the form: cmi_backup/mymodule/configfile.yml / cmi_backup/mymodule/configfile1.yml / cmi_backup/myothermodule/otherconfigfile.yml, etc.

Remaining tasks

Write patch. Optionally, perform UX review if there are user interface changes involved.

User interface changes

TBD.

API changes

None.

Data model changes

None.