Simplify entity-ce-display form and AJAX logic

Agreed, and this is also necessary / a prerequisite to more easily support

• The implications of #3455435: Change configuration structure for CE display 'components': not strictly the implementation of the different config schema, but after we change the UI we'll be able to add multiple formatters for the same field.
• #3446287: Allow configuration of static props

This ticket is an unfortunate mess, at the moment. I have two independent branches:

1.

form-rows-as-components branch. We need to move away from "one row in the form == one field", because in the new paradigm enables us to add one field several times (with different formatters) and we want to support things like #3446287: Allow configuration of static props. This branch will also clean up much of the messy comments / temporary code in the form, that was working towards this situation.

I however shelved this for now. I'm at the point where the basic properties in the form (name, formatter) rebuild and save correctly, but the plugin settings form does not show.

I will likely need to re-index the plugin settings form from "field name" to "new row name" too, and I'm not sure what issues I'll encounter there / how long they will take.

So I shelved this, and will continue working on this later (probably in a followup issue that is going to be a prerequisite for #3446287: Allow configuration of static props if not #3446287 itself -- maybe titled "allow a field to be added multiple times").

2.

3446485-ajax branch. Form row names are still named after the fields.

• I hacked some more temporary helper code in order to build only the fields used by the CE display in the "Content" region (instead of all of them, as the Core form does
• (This requires EntityDisplayFormBase::form() to be copied wholesale into the form, and then changed)
• (and will very likely require a modified 'field_ui_table' form element, so I copied the FieldUiTable class to CustomElementsFieldUiTable, to be freer in hacking away the field_ui JS)
• ...and only the fields which are not in those rows, can be aded using the "Add" AJAX functionality.

However, I have not yet done anything substantial yet, like

• added an AJAX callback to the "add" select element
• untied Core AJAX functionality from the "name" row element (which should not have a callback, it just causes a bug, per the bold warning that is now on the screen)
• check how to implement the deletion. (Deletion is possible currently by explicitly selecting "Disabled" in the region dropdown, and then saving. That is obviously not good UX.)

I have 60-90 minutes more to hack on this before I'm yanked away, and then..... we'll need to plan next steps for the coming 6 days while I'm basically gone. Or: not plan, and I'll pick this up immediately as soon as I can / as I return.

Current status of the "3446485-ajax" branch (rebased on current 3.x and tidied): Two out of three points in the previous message are implemented:

• untied Core AJAX functionality from the "name" + "is_slot" row elements, so those bugs are gone.
  • I needed to clone the field_ui JS library for this, into the module - just to make one little change. But I guess we expected that already.
• I did keep the "region" dropdowns as a means for deletion, because anything else would have required hacking tabledrag.js as well. IMHO this is "good enough" and if we want an actual delete button, that would be a post-stable-release followup.
  • The "region" selector is now always shown on screen, and renamed to "Delete?". See screenshot.
  • "region" is removed from the config schema now. I think this requires no CR because this is auto-removed on save, and we never did anything with the value anyway.

Left to do: the (AJAX) functionality for adding a field to the display.

You're right. I moved the "delete dropdown" to the right.

Things are working now. I think I tested everything.