Ability to add a field multiple times

Wider summary (and retroactive plan / justification)

When I saw we needed to both change the UI ( 📌 Simplify entity-ce-display form and AJAX logic Active ) and support non-field plugins ( ✨ Allow configuration of static props Active ), I had the feeling that the needed changes would be fundamental and interrelated.

However, I had no idea about formatter plugin managers, the structure of the existing Field UI/form code, its JS / tabledrag, etc. So I could not precisely plan the needed steps and their order beforehand, and just started to hack and see what would come out. Which I could never write up because step 1 needed to be finished before I really knew things.

Now I know some more things, so so here's the 'retroactive' plan:
(The ordering and detailed content of the steps has partly been influenced by deadlies.)

1. Change the config structure to be able to support the further steps: 📌 Change configuration structure for CE display 'components' Active
   • This means the config structure (with rows not necessarily corresponding to field names) temporarily does not fit the UI. (Also, I already tried to accommodate for step 4 where possible.) So, ugly 'glue' code needed to be added temporarily.
2. Change the UI to only show fields that are actually configured: 📌 Simplify entity-ce-display form and AJAX logic Active
   • This is big enough to be its own issue.
   • It does not fix any of the 'ugly glue code'; it only introduces some checks that the config entity actually fits onto the currently-possible UI.
3. Introduce the possibility to add a field multiple times. (This is the current issue.)
   • This will force us to drop the forced connection between 'field name' and 'internal row name in the form' -- including the plugin configuration forms
   • ...which at the same time cleans up most of the 'ugly glue code' (because the form will naturally fit the config schema again)
   • ...and which is necessary for step 4.
   • We may or may not get rid of the EntityCustomElementsDisplayEditForm extends EntityDisplayFormBase, because by now there is little code in EntityDisplayFormBase that's still being used.
4. Introduce (the possibility to add) our first non-field formatter: ✨ Allow configuration of static props Active
   • EntityCeDisplay::getRenderer()'s return value will need to be widened because these other formatters cannot be CustomElementsFieldFormatterInterfaces. This is officially a compatibility break.
   • It feels to me like several helper methods in EntityCustomElementsDisplayEditForm are better off moved into CustomElementsFieldFormatterPluginManager, for better understanding / to separate the logic. Also, maybe EntityCeDisplay::getRenderer() is better off calling a helper function in the plugin manager.
   • By this point, all 'ugly glue code' should be gone.

Problem/Motivation

Step 3 should be done in this separate ticket. The outcome (being able to add a field multiple times with different formatters) isn't super major, but we can do most cleanup (if not further planning of a separate followup step) before we do step 4.

It also provides an opportunity (+ necessity) to prove that decoupling a field configuration plugin form from its field name. actually works. (Because we can't index them by field name anymore.)

It's not super urgent, but I would rather not subject anyone to my ugly glue code longer than needed.

Proposed resolution

There is a branch 'form-rows-as-components' in the repo for 📌 Simplify entity-ce-display form and AJAX logic Active . It should be rebased.

Next steps after rebasing:

• Plugin forms aren't showing; they should be made to work again.
• Test the functionality.
• Possibly decide on moving some helper functions into CustomElementsFieldFormatterPluginManager already, though this can also wait until step 4.