Convert thunder processors to config; fix/add formatter(s)

Rationale and notes for:

Provide configuration; tell people to import it and uninstall the submodule. (Alternatively: import it already.)

All c_e_thunder's processors are for a certain paragraph type. We want these to be processed by DefaultContentEntityProcessor now - which has a lower priority.

So we can somehow lower the priority of all c_e_thunder's processors... or just uninstall the module. I believe both are equivalent. because it contains no other code.

It should be up to site maintainers to uninstall a module, so we should provide a README that says this + that the module will disappear in the next major version.

As a service to site maintainers who don't read the README, it's probably possible to already import config on an update hook (so that their site probably won't be affected negatively if they do nothing before upgrading to a v4 where the module is gone). But is that worth the hassle? I'm guessing config import on update will always be somewhat brittle, and it's better if maintainers do it themselves and re-export config immediately...

Note that no solution has a guaranteed perfect upgrade path: in theory, a custom processor can be installed for these paragraph types, with a priority lower than c_e_thunder's and higher than DefaultContentEntityProcessor. Upon uninstalling, that custom processor would take over. I believe there's nothing we can do about it except warn in the README.

Fix RawCeFieldFormatter and turn it into a potential 'base class' for field specific formatters that need to set several values from one field (e.g. 'title' and 'href' from a link field). File followup issues as necessary.

It seems like RawCeFieldFormatter hasn't been tested until now:

• It seems to me that addSlot() should likely be setSlot() - otherwise a single field value will always be output as an array. So as-is, it's not suitable for e.g. all our thunder processors. (That's what a test using JSON output says. I'm still going to do more tests.)
• addSlot() and setSlot() code says that passing array values is deprecated, but the formatter happily does that anyway for multi-value fields.
• Also I don't think setting a single value (vs an array) based on the value is the best idea; it should probably be done based on field cardinality, like DefaultFieldItemListProcessor does.

So this issue seems like a good place to change RawCeFieldFormatter based on experience. If it doesn't end up testing multivalue fields, there should be a TODO in the code and a followup issue to do that.

Note that before we do too much custom work to set/output custom formatted values, we should probably support non-CE field formatters, per 📌 Add support for field formatters Active .
I am just noticing LinkFieldItemProcessor, which does setSlotFromRenderArray() instead of setSlot(). Something like this is probably necessary as a separate base-formatter-class. So maybe my 'title + href' example isn't the best.

MR contains nothing much interesting yet; I just created it to dump my comments about the changed test code.

thx, merged test improvements code.

Commenting on the concept:

ad upgrade path: I'd worry about this last. We release a new major, so are free to do breaking changes.
Anyway, I think we should keep the module, but just drop all of the code and only ship with install-time config. That way, we can nicely proof what was done with custom code before, is now simply config. Once we have that we could also add an update function to install the module config, yes, then the update would be given also.

> Note that no solution has a guaranteed perfect upgrade path:
Not needed at all. There is hardly anyone using this sub-module besides us + we are releasing a new major, what already tells the message of: "Big changes, check your things"

> Fix RawCeFieldFormatter and turn it into a potential 'base class' for field specific formatters that need to set several values from one field (e.g. 'title' and 'href' from a link field). File followup issues as necessary.

We still have "Auto" what I think would make sense to do have reasonable default. In most cases auto + raw + any-core-field-formatter should do a great job already.
But yes, if it makes sense to have multiple options, multiple formatters can be added. We might need one for better entity-reference support.

That said, we don't have to keep 1:1 output of the thunder sub-module. It should be comparable, e.g. for links we should at least have those two attributes. If it has more, also good. But it should output the link as an array of data values. So if raw can do that, but has some additional data, that seems good enough.

Maybe generally, a good follow-up for "Raw" would be some optional config that allows one to define a limited list of properties to include.

Review for quick bugfix. Elements conversion will come in a new MR afterwards.

thx, good fix. Merged and setting back to needs-work for the main issue goals.

roderik → changed the visibility of the branch 3446953-fix-uiconfig-bugs to hidden.

roderik → changed the visibility of the branch 3.x to hidden.

Replacement for above: created an MR for this first part (with link paragraphs now 'working') in child issue 🐛 Fix 'raw' formatter, replace 'text' thunder processors Active