CI/QA: start recording code coverage

[jrfnl]

Description

Unit tests: add @covers annotation to all sniff tests

Unit tests: add @covers annotation to all utility method tests

PHPUnit config: set up to allow for recording code coverage

The forceCoversAnnotation attribute will prevent code coverage from being recorded for tests without a @covers tag.

As for recording the code coverage:
By default, a code coverage text summary will be shown and a clover.xml file will be generated in a build/logs directory.
The clover file can be used to generate code coverage reports via a service like Coveralls.

For local development, the clover.xml is not very human readable-friendly and the summary is a little too minimal, so an HTML report would be better.

To that end, a coverage-local script has been added to the composer.json to make it straight forward for contributors to generate the HTML report.
The HTML report will be placed in a build/coverage-html directory.

The build directory is now excluded via the .gitignore file.

GH Actions: start recording code coverage

This commit reworks the test workflow to start running the tests with code coverage for low/medium/high PHP and upload the generated reports to Coveralls.

• It adds an extra "coverage" job which runs only the unit tests with code coverage against low/medium/high PHP.
  This job does not run the CS check as an integration test.
• Makes minor tweaks to the pre-existing "test" job to prevent duplicate test runs for the exact same PHP/custom ini combinations.
  No need to run the same check twice.

The recorded code coverage reports will be available on: https://coveralls.io/github/PHPCSStandards/PHP_CodeSniffer

Includes adding a code coverage badge to the README..

Suggested changelog entry

N/A

[echoix]

I read through all the changes of the files. Seems ok. But my opinion might only be worth for the GitHub actions part ;)

[jrfnl]

I read through all the changes of the files. Seems ok. But my opinion might only be worth for the GitHub actions part ;)

@echoix Thank you for looking this over! I'm still fiddling a bit with the GH Actions script as the test script runs a combination of tasks, only one of which is running the PHPUnit tests.
Xdebug being on makes the other tasks much slower, while those don't need Xdebug in the first place. This is particularly noticeable on PHP 5.4, for which the run now took 6 minutes.

Unfortunately, XDEBUG_MODE=off cannot be used for those tasks as that's an Xdebug 3 feature and wouldn't work on PHP 5.4.

[echoix]

I'm maintaining https://github.com/oxsecurity/megalinter. The biggest job was around 1h. In the second repo I follow, https://github.com/OSGeo/grass , the longest job (when they can run, since they often get queued), it's 1h30 of runtime (but we want to have it faster).

If 6 min doesn't bother you yet, you can do other nice things in the meantime

[jrfnl]

I'm maintaining GitHub.com/oxsecurity/megalinter. The biggest job was around 1h. In the second repo I follow, https://github.com/OSGeo/grass , the longest job (when they can run, since they often get queued), it's 1h30 of runtime (but we want to have it faster).

If 6 min doesn't bother you yet, you can do other nice things in the meantime

😁 Yeah, we have some of those 1 hour+ jobs for the Composer install plugin too.

I don't mind slow jobs if there is good reason for it (more tests, end-to-end tests etc), I do mind when I know the cause and it's preventable ;-)