Implement object oriented hooks

Worth noting, we found an issue with eca_config_schema_info_alter() not firing when the eca_config module was enabled. I was able to work around this by using an OOP hook.

See 📌 Config validation for ECA models Active

Thanks @michaellander for the additional info. I think, though, that we will not switch to OOP hooks with ECA 2.1 because that version also supports Drupal 10.3 and then things would be broken. We will wait for ECA 3.x which will eventually support ^11.4 || ^12 of Drupal core. Note: 11.4 as the lowest version I've just made up, it's not clear yet which 11 release will be the one that won't see too many breaking changes before Drupal 12.

I've worked on implementing object oriented hooks and the Backwards-compatible Hook implementation for Drupal versions from 10.1 to 11.0 according to https://www.drupal.org/node/3442349 →

Some thoughts:

• When implementing this on one of the next major versions that require at least Drupal 11 then I guess we don't need to consider LegacyHook or any other sort of BC layer. Just going all-in for OOP hooks.
• I didn't look any more in detail, but one thing I noted was that hooks are being registered as listeners into the event_dispatcher service - something ECA does as well. Is it maybe possible that we merge some of our hook-related events entirely to OOP hooks, so we could reduce some class definition overhead?

As mentioned before, this will go into 3.x and we don't require BC for it. Also, as the issue fork is a few months old and also has BC in it, etc. I've decided to create a new branch and start from scratch.

And yes, I agree with @mxh in #6 that this will also make a few existing classes redundant, as we can re-use them for this purpose.

jurgenhaas → changed the visibility of the branch 3.0.x to hidden.

jurgenhaas → changed the visibility of the branch 2.1.x to hidden.

This is now fully implemented and tested. The code feels cleaner now, so I'm pretty excited about that opportunity.

Note, that the hook_module_implements_alter can only be implemented the old way, and we had that for eca_form and eca_project_browser to change the order of hook execution. I've removed those hooks entirely, and managed the processing order with an attribute.

Will merge this, when tests are all green, as I don't expect anyone to review this. The changes are massive and hard to compare, as stuff went into different files, so the diff shows big junks of deleted and new code, which doesn't relate to each other.

Another note: auto-wiring was a bit of a challenge, but using aliases in service files resolved it eventually.

And last but not least, I've also disabled manual hook scans by a parameter in the services file.

Automatically closed - issue fixed for 2 weeks with no activity.