[PP-1] Look for recipes in common locations where site builders might keep them

Does Drupal look for modules in more than just core/modules and /modules/*?

I think it would be a safe expectation to say that recipes would only be located at core/recipes and /recipes/*.

#3: Drupal looks for modules in those places, yes, but also in sites/*/modules and within the current installation profile. That said, we don't need to search for recipes in those places, necessarily. I'm on board with keeping it simple and doing what you propose, but IMHO it costs us very little to take advantage of Composer here, and it will allow us greater flexibility if some sites need to put recipes in different places for whatever reason. (I can totally imagine a case where site builders want certain recipes to be in sites/examples.com/recipes, rather than webroot/recipes.)

it costs us very little to take advantage of Composer here,

… this got me thinking … could we do something similar to the way that Drupal core has some "virtual packages" (IDK the correct terminology) to put everything in core/lib/Drupal/Component in its own Composer package?

i.e. if we could put every core/recipes/* in its own composer package, then suddenly everything is perfectly consistent, because then it'd be just like recipes/*: they all are Composer packages for Drupal recipes.

I have no idea how feasible this is though 😅

#3421197: It is impossible for recipes to depend on recipes outside of their own directory → landed 🚀

Removing postpone from ID coz ^^

This has turned out to be critical. See this Slack comment:

I install recipes in /recipes/contrib. If I apply a recipe that calls other recipes in the same folder, they are no longer found.

So the lack of this is breaking sites that are already using recipes. Big problem.

I thought we had preserved the same folder as the original recipe functionality... we should not have removed that.

Okay, well, I think I found a way to test this without having to write a build test, which would be very complicated to do. I'm directly manipulating the InstalledVersions class, yes, but it is a documented part of Composer's runtime API which is available for use by non-Composer code, and I'm not calling any internal or deprecated methods of it.

I think this is probably ready for review.

There are merge conflicts. Moving back to Needs Work.