Create extendibility proof of concept that also serves as documentation-by-example (extensions)

Just so that I can find this issue more easily in future 😅

Reviews from @larowlan, @jessebaker and @larowlan are on the MR, reflecting that here 😊

After resolving some conflicts that were introduced by #3504517: Libraries needed only inside the preview iframe are loaded for the entire UI, I also reviewed the solution, but not leaving specific feedback, there are enough great comments already on the code changes. 😊

I think as a technical concept and achievement, the solution is beautiful. 👏🏻 I also think that as our long-term solution for extensibility, we shouldn't expose such a low-level API as the app's Redux store. Instead, we should define what tasks we would like extensions to do, and with what high-level UX, then design more abstract APIs for those tasks, including purpose-built UI.

I would look at e.g. Shopify apps and Monday.com apps for inspiration. See the pages I linked — these platforms allow apps to specifically define where on the UI their functionality will show up, and what they can do. Some of those can't even specify anything for their appearance, but e.g. add a menu item in a dropdown list that does a specific action. Others are more flexible and allow adding to the UI from an available suite of components. (Also see my comment on providing UI elements.) This isn't very different from Drupal's APIs where you can e.g. add local tasks, menu items etc. using high-level abstractions, without having to worry about where those will show up, or how they will look.

None of this needs to block this issue, I just wanted to voice some thoughts, so we may start thinking about where to take our extensions. The current implementation is as good as it gets with the information we have today, and can serve as a the basis of whatever we end up doing.

I'd like @longwave to confirm that bypassing the library.discovery service is okay.

I think this is all that's left, so setting to NR and assigning to @longwave. FWIW, I think it's okay to merge this with that bypass, and open a follow up to improve that if we don't think that that bypass is a good long term solution.

By the way, the whole dance of finding all the libraries that are XB extensions seems conceptually very similar to service tags and Symfony's new !tagged_iterator. I realize that libraries.yml isn't the same as services.yml, but I wonder if we want to open a core issue to port over a similar capability/syntax to libraries.yml.

@wim leers - @longwave has given a +1 in response to your question here https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...

This just needs a final review I think and can be merged.

On it!

I had 2 remarks: docs (Jesse added those 👍) and a @longwave review of some clever bypassing of a core API. @longwave +1'd it for here, but did confirm the need for a follow-up, which he created: #3506442: Refactor library discovery for XB Extensions and (field widget) client-side transforms. And seems like @effulgentsia implicitly agreed with that too in #13 :)

Now all this needs is a nice screencast or GIF 🙏😇

GIF to follow in #3506195: Render the extensions P.o.C into the Extensions dialog once it's all looking a bit nicer!

Marking Fixed per #20.