Invalidate the whole result cache when a changed package registers a container class

[SanderMuller]

Follow-up to #6086 and a discussion with @staabm. The package-granular result-cache invalidation from #5933 does not invalidate the cache when a Composer package that registers a class in the PHPStan container (a rule or extension, e.g. larastan) is updated.

getChangedComposerPackages() reports the changed package, and the incremental loop then re-seeds only the files that depend on it through code references. An extension package is not referenced by the analysed code, so zero files are re-seeded and the previous results are served from the cache even though a rule changed. projectExtensionFiles does not cover this either, because getProjectExtensionFiles() skips service classes whose file is under vendor/ with no tracked dependencies.

This is a regression from #5933. Before it, any composerInstalled/composerLocks change forced a full re-analysis, which happened to catch this.

The fix: when a changed package owns a class registered in the container (ProjectConfigHelper::getServiceClassNames() resolved to a package via PackageDependencyResolver::resolvePackage()), re-analyse everything instead of only the file-granular dependents. Packages that contribute nothing to the container keep the granular path.

Added an e2e test (result-cache-extension-update): a package ships a rule through its extension.neon, the package is then updated (rule body changed and its reference in vendor/composer/installed.php bumped, as composer update would), and the run must re-analyse everything and report the new rule output. It fails before this change (granular re-seed, 0 files, stale output) and passes after. The existing result-cache-package-update e2e keeps asserting that a normal package update stays file-granular, so this does not over-invalidate.

Closes phpstan/phpstan#14986

[ondrejmirtes]

Please add another E2E project to test. One that doesn't include extension's neon file via includes but registers an extension via phpstan/extension-installer.

[SanderMuller]

Added result-cache-extension-installer. Good call: it showed my first version only detected extensions from the project config, not ones auto-registered by phpstan/extension-installer, so those weren't invalidating the cache. Now it also consults GeneratedConfig::EXTENSIONS, and both e2e projects fail without the fix.

[staabm]

I verified the e2e tests locally and they work as expected. I am not 100% into the impl details of ResultCacheManager.

@ondrejmirtes please give it a final go