field_permissions pollutes field_base feature components

(sorry for dramatic / negative language in issue title)

Problem

Steps to reproduce:
- export a field_base component with features
- enable field_permissions
- visit the field edit form and submit (leaving field_permission setting in its default state)
- update the feature (e.g. drush fu) with the field_base component.

Expected / desired:
No diff in features.

Actual:
A new entry is added in the feature component.

+    'field_permissions' => array(
+      'type' => 0,
+    ),

This will happen on all fields, even if most of them will behave as if field_permissions was not enabled at all.

Proposed change

(possibly in new major version, or even a new module?)

Save the field_permission settings separately from field_base and field_instance.
Save it only for those fields where the setting is not the default behavior.
Save it only for those field instances where the settings is not the same as the field base. (See ✨ Implement field permissions per-bundle (field instance) Needs work ).

Provide one central UI with a list of all field permission settings, with operations to add and remove.
On the actual field edit forms, only leave a link and a report saying "field permission is currently public (default). They can be modified here (link)."

Once we are there, we could make these entries per-role.
And encourage the site builder to only create "rules" (*) for stuff that deviates from the default.
So one entry in the list would be like "Allow translator role to edit field_description on all entity types and bundles.".

(*) I am not talking about "Rules" module here, even though the proposed system might have some similarity.

The system would detect redundant rules and highlight them in the list, but it would be the site builder's choice whether to delete them.