Decorate the SDC plugin manager and allow components defined in code

Thinking about this some more, after having created two issues with very granular first steps towards multiple component types:

1. 📌 Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs Active
2. 📌 [later phase] [PP-2] Prepare for multiple component types: prefix Component config entity IDs with `sdc` Postponed

Then looking at this issue made me realize that #3469610 is seemingly at odds with this issue. (Postponing that issue on getting a conclusion in this issue.)

We want to be able to expose blocks (and layouts, paragraphs for BC) as components.

Do we want to expose all of those as SDCs (meaning: wrap anything that is not an SDC into an SDC), or do we want to expose them as their own thing?

This is a crucial decision, both from a product level POV ("everything is an SDC" is nice and simple, likely helping facilitate a consistent UX) and an architectural POV!

We only need 📌 [later phase] [PP-2] Prepare for multiple component types: prefix Component config entity IDs with `sdc` Postponed if we make the latter choice. That's the direction I imagined this to be going. But this is proposing something different. (I know I gave a thumbs up at #3454519-22: [META] Support component types other than SDC → for ComponentSourceInterface and this direction, but thinking about it more makes me wonder whether that is truly feasible.)

However … if we truly could model everything as SDCs, that'd be very interesting+elegant, of course! 🤠

I'm just not sure if that's realistic, per 🌱 [META] Support component types other than SDC Needs work . For example, for blocks:

1. we'd need to transform each block setting to an SDC prop, which is possible thanks to the schema information in the config schema (block.settings.*)
2. we could then generate a form for it, using exactly the same mechanisms as we currently use for "real SDCs" … but then we'd just not use the existing form definitions for block plugins — is that intentional?
3. what about blocks' support for the "context" system? SDCs have no such concept.

IOW: AFAICT block plugins can do more than SDCs, which is why "wrapping an SDC in a block plugin" seems easy (hence: https://www.drupal.org/project/sdc_block → ), but the inverse (which is being proposed here) seems hard?

That's exactly why I started the table in the issue summary at 🌱 [META] Support component types other than SDC Needs work , and why the + columns are so important. We didn't expand that table yet for Paragraphs.

Are we really confident that we'll be able to do this too for Paragraphs, for which we have product requirement 42. Paragraphs migration? In https://git.drupalcode.org/project/experience_builder/-/merge_requests/68, you seemed to convey confidence about this, @larowlan, but we didn't discuss that in detail.

So: let's double-check before we go down this path. I'd love for this to be true though, and would love to close 📌 [later phase] [PP-2] Prepare for multiple component types: prefix Component config entity IDs with `sdc` Postponed :)

Discussed #2 with @f.mazeikis and @lauriii. No outcomes, just made them aware, to ensure they start thinking about this and participate here 😊

This is a crucial decision, both from a product level POV ("everything is an SDC" is nice and simple, likely helping facilitate a consistent UX) and an architectural POV!

Can we keep SDC API for pure UI Components (card, button, menu, slider, steps, breadcrumb...), as designed by UI & UX designers, published in design systems and implemented by the front developer, instead of trying to fit everything as SDCs?

As a product, XB will benefit of keeping its use of SDC as a clean, single purpose and well defined API, which is doing one thing and is doing it well, without application state nor business logic.

#4: That's the direction I'm thinking would be best too. It's why I tried to capture the consequences (pros and cons) of going with @larowlan's proposal (if I understood it correctly) in #2.

It's why I'm leaning towards 📌 [later phase] [PP-2] Prepare for multiple component types: prefix Component config entity IDs with `sdc` Postponed .

This is where my approach of adding a component source plugin to the config entity came from. We add one for each type (Block, paragraph, SDC) much like media types. Maybe we revisit that?