Add a generic entity reference revisions field processor

Thanks for the feedback. Please see the attached updated patch. Please can you re-review?

@mostepaniukvm
I have been thinking about this some more.

It looks like there are three Processors for entity references that work in more or less the same way:
* ParagraphFieldItemProcessor.php
* EntityReferenceRevisionsProcessor.php
* MediaReferenceFieldItemProcessor.php

As discussed upthread, we could replace the paragraph processor with the more generic EntityReferenceRevisionsProcessor.

I am now wandering whether all three of these could in fact be replaced by a single entity reference processor.

Would that work?

MediaReferenceFieldItemProcessor is special in that it inlines media-entities, what makes sense for media-entities and paragraphs by default. But I don't see this makes sense for e.g. content entities by default, you might want to only render a link, so inlining the whole entity seems to be not a good default here.

If you have specific needs for other defaults on your site, you can still add that to a custom module of course, but in the main module I htink we should make this adjustable.

The "configurable custom elements" work done in 3.x makes sense to fulfill this use-case, so one could configure varying output strategy for entity-reference fields there? Assigning to mostepaniukvm for feedback on this.

@fago
Thanks for your feedback here. I also see it about the same way.
I would implement a Generic processor for entity_reference_revisions field items but not for entity_reference
I would do similar to existing formatter defaults in field types annotations:
- entity_reference field items rendered as links by DefaultFieldItemProcessor similar to core's definition
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/lib/Drupal/...
- entity_reference_revisions render entities by default
https://git.drupalcode.org/project/entity_reference_revisions/-/blob/8.x...

@Leo Pitt Patch looks good now the only thing that I don't sure still is the class name.
To be consistent we would need to change class name. Even though it is quite long I would call it EntityReferenceRevisionsFieldItemProcessor. @fago what do you think?

changes definitely will go to 3.x branch but what do we need to do with the existing ParagraphFieldItemProcessor in 3.x?
I think it's ok to just remove it, his job will be done by newly introduced EntityReferenceRevisionsFieldItemProcessor.

@fago you're right about configurable_custom_elements
It must definitely give more flexibility with any possible entity_reference widgets.

Please see updated patch attached. I have renamed the Processor to "EntityReferenceRevisionsFieldItemProcessor", as suggested.

@fago @mostepaniukvm

- entity_reference field items rendered as links by DefaultFieldItemProcessor similar to core's definition

I don't understand why we would by default render entity_reference items as links. Would it not make sense to render them according to whatever display settings have been chosen for the entity?

So, if my entity_reference field is configured to display the entity as a link, then render it as a link. But if I've configured it to render the referenced item as the full/teaser entity, I would expect it to be displayed as such, and not as a link.

I would expect this (entity_reference fields to respect the display configuration) to be quite a common requirement, and so something that one might expect to work "out of the box".

What do you think?

> I don't understand why we would by default render entity_reference items as links. Would it not make sense to render them according to whatever display settings have been chosen for the entity?

Respecting display settings does not really work, since display-settings use field-formatters, that generate htlm, not custom-elements. But yes, sometimes they are useful. This is what we want to make configurable with the "configurable custom elements" issue mostepanikvm is working on (see related issues and code in 3.x)

Without this configurability, we can only have processors that provide good defaults + custom-ones that special-case output in projects. So this issue can be about improving defaults. I don't think we should embed content of referenced entities by default, with the exceptoin of media-entities or paragraphs, where this is reasonable.