Define what should happen to a feature's components when a feature is disabled

Coming from #1055460: Disabling a feature does not disown content type, there's a need to define in general what should happen to a feature's components when a feature is disabled. Also related: #663136: Provide way to Import views/true exportables back to the database.

What's currently done? For "true" exportables (e.g., Views):

• When a feature is disabled, its components disappear from the site, provided they have not been overridden. For example, a view that is in code no longer exists when the module providing it is disabled.
• If the component has been overridden, the override (forked version of the component, stored in the database) is left intact and now functions as if it had been created manually. If we still follow the Views model, the override becomes a "normal" view.

For "faux" exportables (e.g., a content type), there's less consistency in what happens when a feature is disabled. Some components are left in place, some are deleted. For one component type (dependencies), the admin who has disabled a feature is presented with a list and can manually select which dependencies to leave in place.

The question of what should happen to orphaned feature components is complicated by the potential that a component can be linked to other components (e.g., a view page display is linked in a menu link) or other data on the site (a content type that has existing content). Leaving a component on the site can produce undesirable clutter ("Hey, I thought I'd deleted that feature I installed for testing, why is its junk still here?"), but deleting it could break a site ("Where did that content type go, and how can I recover the content I had?").

Here are a couple of options for what should happen when a feature is disabled.

Option 1: option to retain components

• Any component in the feature that is in an overridden state should be retained on the site and should be equivalent to a component that has been manually created through the UI.
• Any component in the feature that has not been overridden should be offered in a checklist in the cleanup stage (after the feature disabling) for retention on the site. If the user selects to retain the component, it should be saved in a form equivalent to a component that has been manually created through the UI. For example, an overridden content type should be converted into a custom content type (custom = 1, modified = 1, and locked = 0 in the node_type table).

Option 2: each component type has its own retention rules

• [same as option 1] Any component in the feature that is in an overridden state should be retained on the site and should be equivalent to a component that has been manually created through the UI.
• For non-overridden components, each component type should follow one of two patterns. The first is to remove non-overridden components completely from the site when a feature is disabled. The second is to retain the component in a form equivalent to a component that has been manually created through the UI. In deciding whether the component should be retained, a component type can determine whether there are dependencies that would be broken by its being disabled (e.g., for a content type, whether there is content on the site of the given type). (Features could also consult its dependency information, retaining components that are required by remaining enabled features components. So if another enabled feature has a context that references the content type provided by a newly disabled feature, the content type is retained.)

Implementing either one of these options would probably require component types to provide an "override" method, more or less the opposite of "revert".

What do other people think? Other options?