[meta] Make config actions more dynamic

Problem/Motivation

I think it would be useful for a recipe to say, for example, "make this change to all content types". Currently, I'm not aware of any way to do that.

Proposed resolution

In the config:actions section of recipe.yml, I'd suggest we support syntax like in #7:

config:
  actions:
    core.entity_view_display.node.*.*:
      - setComponent:
          field: field_foo
          settings: {}
    core.entity_form_display.node.*.*:
      - setComponent:
          field: field_foo
          settings: {}

In this example, if you know you have instantiated field_foo on every content type (without necessarily knowing the exact names of those content types), you might want to be sure it is visible on the form and view displays of every content type.

We identified several potential use cases for a feature like this (the actual syntax we come up with might vary):

• Adding the same permission(s) to all user roles (#3420209: Allow config actions to be applied to multiple config entities using wildcards):
  

  user.role.*:
    grantPermissions:
      - 'access content'
      

• Affecting the view display of every content type in the same way -- say, by removing a component you don't want people to see:
  

  core.entity_view_display.node.*.*:
    removeComponent: links
      

• Granting bundle-specific permissions to a particular role, for every bundle of a particular entity type (#3420516: Create config actions that can grant a set of bundle-specific permissions for all bundles of an entity type):
  

  user.role.media_creator:
    grantPermissionsPerMediaType:
      - 'create %bundle media'
      - 'edit own %bundle media'
      - 'delete own %bundle media'
      

• Instantiating a field on all bundles of the storage's target entity type (#3420521: Create a config action that can instantiate a field on every bundle of the target entity type):
  

  field.storage.node.field_tags:
    instantiateOnAllBundles:
      label: Tags
      description: 'Add some tags here.'
      

• Changing settings on every instance of a field (#3420209: Allow config actions to be applied to multiple config entities using wildcards):
  

  field.field.media.*.field_tags:
    setSettings:
      auto_create: false
      

• Adding every content type to a particular workflow (#3422821: Add a config action to add entity types and bundles to a Content Moderation workflow):
  

  workflows.workflow.editorial:
    addAll: node_type
      

• Creating a view display (i.e., enabling a view mode) for every content type (#3420209: Allow config actions to be applied to multiple config entities using wildcards):
  

  core.entity_view_display.node.*.foo:
    ensure_exists:
      # The contents of the view display here...
      

Obviously, some of these need to be implemented differently than others. So these cases should be thought through further, and split out into their own issues.

In general, though, I see two patterns in these use cases:

1. The ability to expand the meaning of *. This could be accomplished in a pretty straightforward manner, I think; \Drupal\Core\Recipe\RecipeRunner::processConfiguration() could convert * into a regex, and apply it against all existing configuration names to find the one(s) that the action should apply to. This would add up to a few extra lines in that method. Let's do that in #3420209: Allow config actions to be applied to multiple config entities using wildcards.
2. New config actions that belong only to particular config entity types, allowing them to take advantage of the specific nature and superpowers of those entity types. Examples:
   • A field storage can instantiate itself on every bundle of its target entity type. This would be a new config action that exists only on field storages. We have #3420521: Create a config action that can instantiate a field on every bundle of the target entity type for implementing this; it's not blocked on anything.
   • Adding a particular entity type and bundle (or all bundles of a particular entity type!) to workflows that use Content Moderation. This applies only to Content Moderation. I'm not sure how exactly to approach this, since this actually requires targeting the plugin that backs the workflow config entity. The point is that this config action would be supported only by Content Moderation's workflows. I've opened #3422821: Add a config action to add entity types and bundles to a Content Moderation workflow to figure this out.
   • Changing field (or field storage) settings. (This could be done using the feature being built in #3420209: Allow config actions to be applied to multiple config entities using wildcards.)

   Because of their specificity, I think each of these cases (or any others we think of) would need to be done in their own issues.