Allow to annotate without the use of inline entity form

Uploading my current work as a patch for now, since this issue's fork returns a 404 page in GitLab (https://git.drupalcode.org/issue/external_entities-3475248/-/import) - hopefully that fixes itself soon.

This patch removes the need to use the inline entity form module completely for annotations. The external entity type's annotation fields now also appear on the form display configuration page, where you can configure the position and widgets of these fields as if they were regular fields.

This allows us to remove all the quirks/workarounds in this module to be compatible with inline entity form. I see no reason anymore why one would use inline entity forms for annotations.

The patch currently also picks up the feature requested @ ✨ Filter the annotation field Needs work , including an automatic upgrade path for this.

What I currently still need to test/work on is how this works in combination with translations (e.g. the work being done in ✨ Make external entities translatable Needs work ).

Fork works now. I'm hiding the patch. Latest changes can be seen in the MR.

Could you confirm you changed back of fix I made recently in src/Form/ExternalEntityForm.php.
The fix:

      if (!empty($fm) && !empty($fm->getPropertyMapping('value')['id'])) {

Your version (which was what was there before):

      if (!empty($fm) && !empty($fm->getMappedSourceFieldName())) {
        // @todo When complex mapping is set, we don't get a source field name.

I suspect you had a conflict to resolve and discarded the fix by mistake.
As the @todo said, "$fm->getMappedSourceFieldName()" is not working with complex mapping: it will find a field mapper but that field mapper will not return a source field name, which will lead to an incorrect redirection to the mapping editing page on saving while a mapping can be there and correct.

Basically, since the id field mapping is required, "!empty($fm)" should be enough to discriminate between newly created external entities and ones that have and id field mapped. I added "$fm->getPropertyMapping('value')['id']" part in case, for some reasons, the property has no property mapper set. It should not happen in theory as setting a property mapper is also required for the id field. But I don't trust theory much and we live in the practical world so I preferred to add that (superfluous) test. After thinking, it could still be improved by checking if the property mapper plugin exists/is available... (mays a @todo should be added there in that sense?)

Anyway, you should definitely remove the "&& !empty($fm->getMappedSourceFieldName())" part which is useless and brings problems.

@guignonv
I think that was idd something that creeped into the MR when resolving conflicts. Reverted that change.