Add a code-only (not changeable via UI) "demo mode" flag that Drupal CMS can set and that future XB MRs can use to constrain XB functionality

AFAICT a settings.php setting is impossible, because that'd then mean that everybody working on XB would have to set that 😅

Based on the requirements in the issue summary, I think the following implementation would make sense:

• container parameter
• set by a hidden module
• which is installed by a recipe

Tried it and … nope, any already-installed module appears at /admin/modules/uninstall, even if it gains a hidden: true flag. That also means that the hidden submodule choice is equally simple to undo.

So then … I think still doing what I propose above, but labeling the module or something like that would be reasonable? (Perhaps even without the scary/silly suffix.)

I wonder if it would be sensible for a recipe to be able to set a container parameter?

#3: How could it? Recipes can only install config or perform config actions. A container parameter is outside the realm of config.

Or … is my head so far in baby/diaper/poop land that the poop has affected my thinking? 🤣💩

For #3, I was thinking what if the Recipe system could read something from a recipe's yml file and use that to set something in the database that would affect the container parameter. But, I think that's incorrect as you point out. However, instead of setting a container parameter, it could perhaps set state?

Alternatively, what if "demo mode" is actually the default, and instead there's "canary mode"? In this case, Drupal CMS wouldn't need to set anything, and XB could ship with a hidden xb_canary module that can be enabled via Drush, if you want to unlock XB's full functionality?

> Recipes can only install config or perform config actions.

So let's just use config? We don't have to provide UI, and in a future version of XB when we want to remove the flag, we can force-remove the config via an update hook.