Require label and category properties for layout plugins

Problem/Motivation

Per How to register layouts:

The 'label' and 'category' keys are required.

This came up in #3392572: Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts and #3450760: Add missing 'label' key to navigation.layouts.yml. There was a thought to make the two keys required in the annotation to attribute conversion in #3420983: Convert Layout plugin discovery to attributes, per #2 and #17:

I think we should consider a BC layer where we add a label for unlabelled layouts and trigger a deprecation.

, but then it was kicked back to be done in #3392572: Add missing category to Drupal\layout_builder\Plugin\Layout\BlankLayout and let modules and themes alter the list of layouts, and finally decided to do a separate follow up, which is this issue.

The most direct way to address would be to make the Layout attribute label and category properties required, but some considerations:

• Are there uses cases where layout plugin derivers provide label or category?
• CategorizingPluginManagerTrait::processDefinitionCategory() provides a default category of the provider module name or machine name when the plugin definition is an array. Layout plugin definitions are objects, not arrays, but something similar can be implemented so that the same default category is assigned to the plugin definition when the plugin manager processes the definition

Steps to reproduce

Proposed resolution

• Add label to any current existing core layouts without one
• Trigger deprecation on any layouts that do not have a label
• In LayoutPluginManger:: processDefinition(), add a default category of the plugin provider (see CategorizingPluginManagerTrait::processDefinitionCategory())
• Investigate whether there are use cases for derivers providing plugin labels - There are. See #7.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet