CI: Introduce PHP compatibility check

[Wirone]

Inspired by this finding, bug introduced in #7616, reproduced here - we have invalid return type in code and none of the tools caught this. I thought this is because we run PHPStan on 8.3 which then assumes it's valid return type, but I modified dev-tools/composer.json, allowed PHP 7.4 and checked on it, but PHPStan still did not report it, even on max level. I believe this is a bug (CC: @ondrejmirtes), but anyway I thought maybe it's a good idea to introduce PHPCompatibility check, which is more focused on differences between PHP versions.

This is a draft and CI will fail, because we need to decide how we want to handle dynamic usages of PHP consts etc. I believe that sniffs should not report these problems if constant is used in if condition, like:

if (\defined('T_READONLY')) {
    // Skip readonly classes for PHP 8.2+
    $acceptTypes[] = T_READONLY;
}

but this is separate problem that should be addressed and fixed in long-term (CC: @jrfnl).

PS. There is 10.x-dev as 9.99.0 constraint because 10.x development version has more checks, but at the same time is not compatible with phpcompatibility/phpcompatibility-symfony which handles Symfony polyfills. We've been using this setup for months in GetResponse and it helped us with migration from 7.4 to 8.2, so I assume it as safe enough 🙂.

[coveralls]

coverage: 94.769%. remained the same when pulling 9cdb0057bf94dc0f84a66e6989176c560d1d3b51 on Wirone:codito/phpcompatibility into ea010715849af5b7dd04c49bb910d6875160eee7 on PHP-CS-Fixer:master.

[ondrejmirtes]

Please don't cc me on other repositories. If you want, you can isolate the bug, reproduce it and report it properly on PHPStan's issue tracker.

[github-actions[bot]]

Since this pull request has not had any activity within the last 90 days, I have marked it as stale.

The purpose of this action is to enforce backlog review once in a while. This is mostly for maintainers and helps with keeping repository in good condition, because stale issues and PRs can accumulate over time and make it harder for others to find relevant information. It is also possible that some changes has been made to the repo already, and issue or PR became outdated, but wasn't closed for some reason. This action helps with periodic review and closing of such stale items in automated way.

You may let maintainers handle this or verify current relevancy by yourself, to help with re-triage. Any activity will remove stale label so it won't be automatically closed at this point.

I will close it if no further activity occurs within the next 14 days.

Please keep your branch up-to-date by rebasing it when main branch is ahead of it, thanks in advance!