Remove the plugin-only PHPStan workflow and pre-push hook

[snake14]

Description

Draft, opened to make the option concrete while we settle where plugin CI tooling should live — see the discussion on #49. Please do not merge before the replacement home exists.

Removes the two things in this repository that target plugins only, while this action serves both core and plugins:

• .github/workflows/plugin-phpstan.yml (added in Add a reusable PHPStan workflow and the canonical pre-push hook, PG-4897 #44)
• hooks/pre-push, the canonical copy of the plugin PHPStan pre-push hook
• the ## Reusable workflows and ## Git hooks README sections that document them

Deliberately kept: the scripts/bash/checkout_dependent_plugins.sh hardening that also came in with #44. That script is called by action.yml itself, so it belongs here regardless of where the plugin workflows end up.

Nothing consumes the removed workflow yet — the only reference to plugin-phpstan.yml anywhere in matomo-org or innocraft was the README section this PR deletes — so removing it now costs a single move, whereas doing it after the per-plugin rollout would mean a PR in every plugin repository. That is the main reason to decide sooner rather than later.

The matomo5_min_php-style alias table is intentionally not part of this PR. #51 moves it out of action.yml into scripts/bash/resolve_php_version.sh, where it stays: it is shared by core and plugin CI alike, and a workflow in another repository can resolve it by checking this repository out at a pinned ref, which is how plugin-phpstan.yml already consumes the other shared scripts.

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done see checklist
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed