Make ModuleActivator expose a Configure follow-up task for modules which have one

Added credit for Adam since this was an idea from him at NEDCamp 2022. And I think it's a great one, but would require additional module maintainer contributions, such as adding "now what" steps in the info.yml or to a known help file or something. core-post-mvp is perfect.

I fixed some typos in the issue summary.

I added keywords like settings and link.

I also expanded the scope, by suggesting we link to the module config page.

Do folks think linking should be a separate issue?? Maybe it's not dependent on module maintaining writing text. And so linking might get implemented faster?

+1 for a solution to give instruction to the user once a recipe is applied.

I had this issue after installing the "Search" recipe on a fresh Drupal CMS install.

The installation works because the recipe's button now says "Installed" but - as a site builder - I have no idea what to do next.

Recipes should provide a way to display message and/or redirect the users to another page.

I think I see a path forward here: let recipes optionally define a set of follow-up tasks, which are then exposed in the Project Browser UI as items in a drop button.

Recipes would be able to have something like this in their recipe.yml -- a set of follow-up links:

follow_up:
  project_browser:
    -
      text: Configure
      route_name: some_module.settings
      route_parameters:
        foo: bar
      options:
        query:
          hello: goodbye
    -
      # Another struct like the one above...

Astute readers will recognize that repeatable struct as a dehydrated \Drupal\Core\Link object. So the recipe could define as many follow-up links as it wanted, in that format. Project Browser would then display those links in a drop-button, probably in the project detail modal, once the recipe was in the \Drupal\project_browser\ActivationStatus::Active state.

There are two blockers to this.

1. Core needs to allow recipe.yml to contain a follow_up field. Rather than formalize that structure in core right now, I propose we simply relax the validation in \Drupal\Core\Recipe\Recipe::parse() so that recipes could expose additional data to specialist modules like Project Browser. This would be a one-line change in core (apart from test coverage); no other validation constraints would change. Think of it as the recipe equivalent of the extra field of composer.json. This will be added in #3503190: Allow recipes to contain an "extra" property with arbitrary information for specific modules to use.
2. #3502666: Replace install/select button with a Drupal-standard drop button would be the other blocker; we'd need the ability for a project to present a set of action links to the Svelte app, which then get rendered in a drop button.

Thoughts?

Postponed on #3505159: Allow recipes to expose additional follow-up tasks to Project Browser, which is the overarching plan for implementing #10.

This is actually blocked by #3505592: Activation information should be delivered to the frontend by a dedicated service.

Blocker is in!

This is ready for an initial review. Probably needs test coverage, but that could be a kernel test covering ModuleActivator.

Test written, pretty straightforward.

Tagging for an IS update.

Thanks, all! For contributions great and small :)