[policy, no patch] Add a "developer tooling" topic to Drupal core

What is the problem to solve?

Providing a topic with maintainers for introduced deprecations.

Who is this for?

Drupal core developers

Result: what will be the outcome?

Catalyst: #3265945: Deprecate plugins using annotations and plugin types not supporting attributes

Drupal has adopted phpstan-drupal and drupal-rector as official tools the community maintains for handling and fixing deprecations. However, often, Drupal core makes changes faster than the tooling can support.

I am proposing a new subsystem topic with its maintainers to help handle this problem and create a gate. This had been discussed before, such as adding checkboxes to CRs requiring issues for phpstan-drupal and drupal-rector.

Regarding a responsibility assignment matrix, the deprecations topic maintainers would be Consulted and Informed. They would provide domain knowledge if PHPStan can detect an implemented deprecation or if phpstan-drupal requires a new Rule or other changes. Then, a proper issue can be opened for the project—the same for the scope of impact on drupal-rector for an issue to handle automated fixes.

I am proposing Björn Brala (bbrala) and myself for this. Currently, we're using this repo to automate the import of change records to track work needed for phpstan-drupal and drupal-rector https://github.com/mglaman/drupal-change-record-triage/issues

This topic would make it an official process and add a sign-off gate for new deprecations. Each Driesnote discusses the ease of upgrading Drupal with automatic fixes. This adds procedures and policies in place to ensure this is true.

One concern is blocking innovation on approval from these topic maintainers, especially if it's only two people to start. This would be streamlined once phpstan-deprecation-rules (#3263109: Use PHPStan for deprecation checking) is officially adopted. It is already available, and errors are added to the baseline (see https://git.drupalcode.org/project/drupal/-/blob/11.x/core/phpstan-basel....) If a deprecation is added and PHPStan doesn't fail, the topic maintainer must be consulted. For Rector, as drupal-rector grows with more configurable rules, it should scale over time. Deprecations and fixes should be less one-off and more about adding a newly configured rule since most deprecation fixes follow similar patterns.

Only complex deprecations, such as deprecating plugin annotations for attributes, will warrant longer blocking conversations. That's okay because I currently feel the pain and urgency once it has been committed and phpstan-drupal users fail to detect the deprecations.

Proposed solution

Add a Developer Tooling topic to core.

Remaining tasks

1. Define
2. Review by community
3. Review by product managment team
4. Review by core leadership team team
5. Create followup governance, to add the role, tag, description and such. #3536493: Add a developer tooling topic to Drupal core
6. Create followup core issue, to add maintainers
7. Create followup core issue, to define the core gate #3543735: Define core gate for 'developer tooling'