Package Manager should not restrict which packages can do scaffolding

Drupal CMS can work around this for now, but it's still a release target.

@catch and I discussed in Slack. Here's what was said:

catch: What is the actual scaffolding that is being broken? From the recipe itself?
phenaproxima: So, Drupal CMS 2.x allows drupal_cms_seo_tools to scaffold a file -- a snippet to append to robots.txt.
This is a necessary thing, and fixes a long-standing bug that affects the entire 1.x line. (edited) 
Here’s the scaffolding it’s doing: https://git.drupalcode.org/project/drupal_cms/-/blob/2.x/recipes/drupal_cms_seo_tools/composer.json?ref_type=heads#L24

catch: OK I see, so it's just using the scaffold plugin API, but package manager is not happy.
phenaproxima: Right. Package Manager is saying “thou shalt not scaffold” even though it’s something that only the site owner can do, with explicit intent.
catch: Well it's not the site owner though in this case is it?
phenaproxima: It absolutely is: https://git.drupalcode.org/project/drupal_cms/-/blob/2.x/project_template/composer.json?ref_type=heads#L68
catch: If I have Drupal CMS on shared hosting, and I install this recipe, then the recipe would overwrite robots.txt on production.
phenaproxima: It would append to robots.txt in production, but if you don’t want it to, just change the allowed-packages line in the top-level composer.json. Done. This is how any scaffolding works, Drupal CMS or no Drupal CMS.
catch: There is no 'just' for people who don't want to edit json, but I guess the main bit is the only people who can allow it are the site owner or Drupal CMS, not any random recipe on d.o
phenaproxima: That’s correct.
Scaffolding won’t “just happen” willy-nilly.
catch: And you could write a sneaky module that undoes the validator if you really wanted to workaround it. Not that anyone would do anything as nefarious as that :wink:
phenaproxima: Drupal CMS would never hack around core <del>dumbness</del> mistakes. Never! =P
catch: Seems fine to drop this and maybe in a patch release, would be good to c&p a bit more of ^^ into the issue.

Linking the issue where (I think) the restriction was introduced. It has a very detailed explanation of the rationale.

I still think we should remove it. Package Manager in contrib, and Automatic Updates as well, have in some cases put guardrails in place that may have seemed reasonable in theory, when Package Manager was not a critically important part of the default download of Drupal -- but those guardrails break workflows and frustrate people in the real world. We need to reevaluate many of those decisions and make a realistic assessment of whether they are really adding safety, or just adding friction in the name of safety.

The related issue's summary imagines some very bizarre, hacky uses of the scaffold plugin that I'm not sure anyone actually does in real life. But even if such cases exist, the scaffold plugin will not perform scaffold operations defined by any package not explicitly trusted by the site owner. So I think the rationale for that issue maybe never made sense; why that "only trusted packages can do things" bit was missed, I am not sure.