Remove Implements comments once the api can pickup hook implementations from classes.

I would assume that api module can't properly pick up #Hook methods, whether or not they have the Implements docblock, so I'd assume that's not really a blocker, it's already broken without that change.

What I think is a blocker of this is a coding standards issue to change the requirement around this. We need to change this bit: https://www.drupal.org/docs/develop/standards/php/api-documentation-and-....

That means we need an issue in this project: https://www.drupal.org/project/coding_standards. See #2140961: Allow constructor methods to omit docblocks for the example that changed the requirements around constructor params.

> I would assume that api module can't properly pick up #Hook methods

A proof of concept for that already exists in #3471763: API-docs support for OO hooks implementations in classes but we decided it's better to properly support attributes and then special case from there. Attribute support branch is up at #3449634: Attributes are not rendered when showing the source code we need a test, I will write one when I get to it, help is always welcome.

I'd like to get #Hook api support out by the time D11.1 lands. We will see whether time permits.

That was maybe a bit unclear, let me expand: "I assume that API module currently out of the box would not find class methods as hook implementations, whether or not there is a 'Implements hook_foo()' docblock and therefore having or not having those docblocks is not relevant or api.module. It needs adjustments to find those and these adjustments will not look at the comment string anymore.".

Nic pointed me to this issue and I just wanna slap a big fat +1 on dropping the comment.

An example from my conversion in Group:

  /**
   * Implements hook_help().
   */
  #[Hook('help')]
  public function help(string $route_name, RouteMatchInterface $route_match): string {
    return match ($route_name) {
      '...' => '<p>' . '...' . '</p>',
      default => ''
    };
  }

I mean, I think it's clear enough judging from the attribute and method name what we're dealing with.

Having said all of that, I agree that making the docs support attributes is probably the best way forward as more systems can benefit from that now that we're moving so much stuff over to attributes (e.g. entity type definitions).

Unfortunately removing that from the docblock would make it harder to search code for hooks that have placeholders in the name.

We now have for example:

  /**
   * Implements hook_ENTITY_TYPE_presave().
   */
  #[Hook('view_presave')]

  /**
   * Implements hook_ENTITY_TYPE_presave() for blocks.
   */
  #[Hook('block_presave')]

Keeping comments for dynamic hooks makes sense for discoverability.
For static hooks, however, removing the redundant “Implements hook_*” comments would help keep the code cleaner.
Perhaps we could limit removals to non-dynamic hooks only.