Integrate PHPStan into the core development workflow

[westonruter]

​PHPStan is a vital static analysis tool for identifying bugs in code. Previously it has been used to identify problems in core by manually running PHPStan on the core codebase:

• #58852
• #57782
• #51423
• #52217
• #59653

As @johnbillion suggests in #52217:

Consider whether it's beneficial to add PHPStan (or Psalm or Phan) analysis to the build tooling and CI.

I suggest we incorporate PHPStan now into the workflow with a populated ​baseline that captures all of the existing issues and ignores them so that everything doesn't have to be fixed up front. This baseline will then allow new issues to be reported as they are introduced in the codebase, again without having to fix everything up-front.

We can start with either ​rule level 0 or 1 and then go from there as we fix issues in the codebase. It may not make sense to implement the highest levels.

For reference, the Performance team has implemented PHPStan as part of the Performance Lab codebase and there have been separate PRs fixing issues for each level (​1, ​2, ​3, ​4, ​5, ​6, ​7). It is remarkable how effective it is at identifying problems.

PHPStan should be run alongside PHPCS in GHA and locally as part of the pre-commit checks.

[jorbin]

There is a PR in ​https://github.com/WordPress/wordpress-develop/pull/853/files that is stalled that I think could serve as the starting point once the discussions there can come to a satisfactory conclusion.

[oglekler]

We have 1 week before Beta 1, and it looks like patch is not exactly ready. If adding PHPStan itself is not affecting code directly, then changing some default values can. I propose to split PHPStan addition and suggested code fixes.

[oglekler]

We have just a few days before Beta 1, so, I am moving this to the next milestone for further investigation.