Remove tight 1:1 coupling between config entities and components: allow multiple Component config entities using the same SDC

This prevents non config entity components as well as multiple different instances of the same component

(Emphasis mine.)
@lauriii, do you want that to be supported? This is not answered by the product requirements.

@larowlan I'm only concerned about that one bit, the "non-SDC components" part makes sense 👍

FYI: the tight coupling itself is being solved in 📌 Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs Fixed :)

Retitling/rescoping for what I emphasized >1 month ago in #3.

This prevents non config entity components as well as multiple different instances of the same component

I'm not sure I could think of a good use case for this, at least one that couldn't be achieved by taking another approach. Maybe @larowlan who originally proposed this could elaborate what a good example use case for this would be?

I suspect Lee is thinking of e.g. creating >=2 Component config entities for the experience_builder:heading SDC (for example), one with it preconfigured to <h2>, one with it preconfigured to <h3>.

@larowlan is that right?

At one point we were talking about default values being saved in the config entity

I think that was the use case.

I don't think we're doing that anymore

But with the work to support other components (eg blocks) this is probably not needed anymore

The main driver here is to get rid of the magic config entity id to SDC plugin, which the source plugin work Felix started does anyway

Great! 😊 Thanks!