[PP-1] Allow fields to be marked as non-exportable

Postponed on the export command.

The implications of this issue are significant. I think we should do it, for sure -- if we do, it will allow us to remove a great deal of special processing from the ContentExportNormalizer we're adding in ✨ Add a command-line utility to export content in YAML format Active .

The more I think about this, the more I think we probably want to add a new top-level exportable key to field configuration entities (i.e., field_config and base_field_override). Having it as a setting of the field type plugin is more complex and is asking for backwards compatibility and update path headaches. Adding a new top-level key is straightforward.

More thoughts, which I shared with committers on Slack:

A few thoughts here, based on a point someone raised in a postponed follow-up — right now, ✨ Add a command-line utility to export content in YAML format Active includes some low-level but probably harmless hacks (like the do not export setting) to prevent certain properties/fields from being exported. I think that, in a follow-up — or really, probably a raft of follow-ups -- we might want to formalize the concept of “exportability” at the data layer level. Semantically, “exportable” could be similar to “internal” — it’s up to the calling code to decide what it means and what to do with it. But we might want to add a DataDefinitionInterface::isExportable() method — not sure how disruptive this would be?

✨ Add a command-line utility to export content in YAML format Active implemented a mechanism for doing this dynamically, so this maybe needs a rescope to decide if we even want to implement a field-level "exportable" setting.

Core blocker is in.