Split the monolithic recipe into composable component recipes

Problem/Motivation

Today drupal/plus_suite ships as a single monolithic recipe. Applying it installs the whole suite plus a landing_page content type, image and layout_block block types, the optional editorial block types, the non-Layout-Builder inline editing extra, and demo content.

That is ideal for a greenfield site, but wrong for an existing site that already has (say) a landing page type, or that wants the page builder experience without these block and content types. There is currently no way to take only the pieces you want.

Proposed resolution

Split the single recipe into composable component recipes, kept inside one composer package so installation stays a single composer require drupal/plus_suite. An existing site applies only the components it wants; a new site applies the umbrella and gets everything, exactly as before.

Structure (all under the one package):

recipes/plus_suite/
├── composer.json            (unchanged require list: all suite modules)
├── recipe.yml               (thin alias to the nested umbrella, kept for CI detection)
└── recipes/
    ├── plus_suite              umbrella: composes every component below + demo content
    ├── plus_suite_base         module installs, config import, config actions
    ├── plus_suite_layout_block
    ├── plus_suite_image_block
    ├── plus_suite_heading_block
    ├── plus_suite_cta_block
    ├── plus_suite_teaser_block
    ├── plus_suite_non_lb_node
    └── plus_suite_landing_page

Key points:

• One composer package, components nested inside it. No separate drupal.org projects or Packagist packages. The package require list (navigation_plus, lb_plus, edit_plus, and the rest) guarantees every module is present for every component.
• A plus_suite_base engine recipe does the shared work: module installs, config import, and the config actions. Every other component lists recipes: [plus_suite_base], so applying any component pulls in base automatically.
• The umbrella sits as a sibling of the components and composes them by bare name. Core resolves a bare recipe include relative to the applied recipe's own directory, so it works from any apply path. A docroot-relative slash include would break under the test harness and CI, which apply recipes by absolute path. The cost is one extra path segment on the "apply everything" command.

Apply commands:

drush recipe ../recipes/plus_suite/recipes/plus_suite               (everything)
drush recipe ../recipes/plus_suite/recipes/plus_suite_landing_page  (just one component)