[meta] Clean up .info.yml files

Re @dww on #1398772-118: Replace .info.yml with composer.json for extensions:

There’s also talk of a dedicated regions.yml file for defining theme regions.

Where is this discussion happening? Without knowing more, moving regions from info.yml to regions.yml feels like a poorman's refactor, in light of what I had in mind with making theme settings first-class Config Management citizens. Eg, themes would provide default regions prop in config/install/[themename].settings.yml, where they could then be managed (CRUD + reordered + grouped + attributes) via the UI, and synced with config management via Drush like the rest of Drupal. This is kind of an interesting first step to having a hybrid control of theme region layout exposed to a decoupled frontend via a structured data object.

Remaining Tasks: Create subtasks to clean up the .info files.

Seems like there is a lot of definition work and brainstorming to be done. (each property in the info file may need to be moved in a different way). Was the intention to have a different meta per type (module/theme/profile) to further break down the work, or to shop around ideas for all three types here and try to coalesce around common properties that would be cleaned up in similar ways, then come up with actual process steps required for getting it all done, into subtasks?

Re: #4: See, e.g. #1398772-79: Replace .info.yml with composer.json for extensions from @catch in 2015, and some subsequent comments. I don't know of a dedicated core issue to discuss it in full. What you're talking about sounds interesting, but perhaps over-complicated. I'm not as much of a front-ender, but in my experience, theme regions seem pretty hard-coded and baked into the theme. The ability to dynamically add/remove/reorder them via the UI seems fraught with peril. 😉 So what if I click/drag a new region into existence? Don't I have to manually update various Twig templates to support it? Seems like the hard-coded metadata list more accurately reflects reality than exposing this to CRUD via the UI.

You're right that moving existing functionality to a new file, a la regions.yml, as hardcoded metadata would accurately reflect reality.

I guess what I'm getting at is that using config mgmt instead of regions.yml would set the stage for more improvements in the future. Those improvements I mentioned are all out of scope of this refactor. Let's say we don't expose a UI for the regions. Must everything in a config yml file be exposed in the UI? (I feel like I've worked with cases where certain module configs use CMI but don't explicitly expose all their settings).

Even if we had to make a UI for it, I feel like themers are intimately familiar with the concept of clicking something into existence in the UI, and then manually CRUDing templates in the theme to match that reality, so this doesn't feel like so much of a leap of faith. And, bonus, if the project is using drush cex/cim to sync code with database, then there is nothing really new here to learn.

per #6