Use setup-php instead of php-actions so that all CI steps are run using the same PHP version

[osma]

Reasons for creating this PR

While working on PR #1648 , I noticed a problem with the way we run PHP-CS-Fixer under GitHub Actions. We use php-actions/composer and php-actions/phpunit for running Composer and PHPUnit using selected PHP versions (currently 8.0, 8.1 and 8.2) inside a separate container. However, PHP-CS-Fixer is run using the PHP version provided by the Ubuntu base system, which is currently 8.1. This causes a problem when Composer, running under PHP 8.2, installs some dependencies (in this case Symfony 7 modules) that are not compatible with PHP 8.1, causing the PHP-CS-Fixer step to fail.

It seems that it's not easy to run PHP-CS-Fixer using php-actions containers, as there is no action specific to this tool. So instead this PR changes our GitHub Actions CI workflow to use the setup-php action instead, which works a bit differently than php-actions. Setup-php installs the desired version of PHP within the base system and then the subsequent steps in the workflow can run Composer, PHP-CS-Fixer and PHPUnit all using that same PHP version.

The workflow seems to take around 6 minutes to run, which is about the same as before, possibly a little bit faster, but there is a lot of variation so it's a bit hard to say. At least it's not significantly slower!

Link to relevant issue(s), if any

• fixes a bug that was triggered by Symfony dependencies installed as part of Use Symfony Translations to synchronize translations with Lokalise #1648

Description of the changes in this PR

• Replaced php-actions/composer with shivammathur/setup-php for setting up PHP and installing Composer dependencies using composer install.
• Replaced php-actions/phpunit with a direct command to run PHPUnit tests using ./vendor/bin/phpunit.
• Added PHP extensions and coverage tool configuration in the setup-php step.

Known problems or uncertainties in this PR

Not 100% sure about whether the caching behavior is correct, but the only way to find out is to use this for a while..

I noticed that some of the actions we use are older versions that probably should be upgraded. Also we could consider upping the PHP versions (drop 8.0, add support for 8.3) and use a newer Node.js version in the workflow. However, those are a bit out of scope for this PR that just switches to setup-php.

Checklist

• phpUnit tests pass locally with my changes
• I have added tests that show that the new code works, or tests are not relevant for this PR (e.g. only HTML/CSS changes)
• The PR doesn't reduce accessibility of the front-end code (e.g. tab focus, scaling to different resolutions, use of .sr-only class, color contrast)
• The PR doesn't introduce unintended code changes (e.g. empty lines or useless reindentation)

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[joelit]

All I can say is that the new dependency seems pretty well maintained and documented. LGTM