Additional permissions added for Layout Builder

Before #2914486: Add granular permissions to the Layout Builder, there was only one permission exposed by Layout Builder: configure any layout. This permission granted almost unfettered access to the layout builder, as long as you had access to the "thing" which hosted the layout (e.g., a node or other layout-able entity; an entity view display, etc).

Three new layout permissions

New permissions are now available, allowing site builders set up more refined access handling. For every bundle of every layout-able entity type, two permissions are exposed:

configure all $bundle $entity_type_id layout overrides

Allows access to any layout attached to entities of the given type and bundle (for example, layout overrides for any individual "Article" content item).

configure editable $bundle $entity_type_id layout overrides

Grant access only to layouts attached to entities of the given type and bundle which the current user also has permission to edit (for example, a layout of draft content the user may edit, but not a layout of another user's content).

Note that the above permissions apply only individual layout overrides. Configuring the default layout for an entity type still requires both the administer $entity_type_id display and configure any layout permissions.

Additionally, a new permission for adding custom blocks from within Layout Builder has been added:

create and edit custom blocks

This permission allows the layout editor to add new content to the page with single-use custom blocks. Users without this permission will only be able to place existing content blocks on the site. (Previously, the configure any layout permission itself provided this functionality.) This permission is required to add custom block content to either default layouts or layout overrides.

Updating your site's Layout Builder permissions

Existing sites will be automatically updated to grant the create and edit custom blocks permission to roles that already have the configure any layout permission. This ensures that there is no change in functionality for users already using the Layout Builder module.

The original configure any layout permission is still available. As a best practice, that permission should be given only to administrators. Review your site's permissions for the Layout Builder module. Consider removing the configure any layout permission from non-administrative roles like content editors, and instead grant those roles one of the new per-bundle permissions for the specific types of layouts they should be able to edit.

The create and edit custom blocks permission allows creating new content on the site (in addition to placing existing content from entity fields and site blocks). Consider removing this permission from roles that should not be able to create new content on individual layouts.

Overriding access control for a storage plugin

A new handles_permission_check annotation key has been added to section storage plugins. By default, the configure any layout is used when accessing the Layout Builder UI or any of its underlying routes; however if handles_permission_check is set to TRUE, the "configure any layout" permission will not be added, and the section storage will be entirely responsible for determining access to the route in question.

All route access checking is now handled by \Drupal\layout_builder\Access\LayoutBuilderAccessCheck. \Drupal\layout_builder\Access\LayoutSectionAccessCheck is now deprecated and replaced by LayoutBuilderAccessCheck. Modules should replace any usages of the _has_layout_section requirement with a _layout_builder_access requirement.