Add hook_inline_entity_form_[entity|ENTITYTYPE]_prepare_form

The patch on #2 for me, just a minor fix on the $entity parameter

The patch is working fine. I was able to apply the patch using Composer. Then I added hook_entity_prepare_form() in a custom module and made sure that the code in this hook is being executed.

1. +++ b/src/Form/EntityInlineForm.php
   @@ -225,6 +228,27 @@ class EntityInlineForm implements InlineFormInterface {
   +    $implementations = $this->moduleHandler->getImplementations($hook);
   +    foreach ($implementations as $module) {
   +      $function = $module . '_' . $hook;
   +      if (function_exists($function)) {
   

   What's the reason for building the function name rather than using module handler's invokeAll()? This should be explained in the comments.

2. +++ b/src/Form/EntityInlineForm.php
   @@ -225,6 +228,27 @@ class EntityInlineForm implements InlineFormInterface {
   +        // Ensure we pass an updated translation object and form display at
   +        // each invocation, since they depend on form state which is alterable.
   +        $args = [$entity, 'add', &$form_state];
   

   I don't understand how the comment relates to the code. Where or what is the updated translation object?

Just a minor hint is that the suggestions and questions reported in #5 apply also in core from which this patch has been based https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!EntityForm...

Thank ya all! Setting major as this violates a basic API expectation.

As of #5/#6: An updated patch should state where that code is copied from (no shame ;-). And rewrite comments that probably had been copied but not adapted before (shame!).

Re-roll #3 for 10.0.x

#8 is in
tnx

Bulk reopen.

I still like this a lot. Revisiting this after quite some time, my gut feeling is that this must not re-purpose hook_entity_prepare_form, but invent an IEF version of it. (Anyone with a good reasoning that it is not so, please explain!)

The related issue confirms that this implementation is wrong and must not be committed.
An IEF version of that hook makes sense though.

This seems to have caused some major regressions. See #3364996: Parent form entity builders run on IEF resulting in fatal errors

#14:
> still like this a lot. Revisiting this after quite some time, my gut feeling is that this must not re-purpose hook_entity_prepare_form, but invent an IEF version of it.

Comment #3364996-15: Parent form entity builders run on IEF resulting in fatal errors of that issue elaboratest that brilliantly.

Updating title accordingly.