Remove `phpdbg`, migrate to `pcov`

[Ocramius]

See sebastianbergmann/php-code-coverage#945

According to upstream maintainers, phpdbg coverage support is not really maintained, and we should therefore migrate away from it.

We will likely need to ship pcov with our container, and use that for running tests.

We may also need to remove phpdbg, since running phpdbg with pcov installed leads to segfaults.

[Ocramius]

PHPDBG support has been removed right now: sebastianbergmann/php-code-coverage@c304be7

[Ocramius]

PHPUnit 10 pulled the plug and switched over: will prepare a patch for this, since we can otherwise no longer run coverage reports (which breaks mutation tests)

[boesing]

Careful:
https://github.com/laminas/laminas-ci-matrix-action/blob/ca11cee53aec05d9cc301993585c316d27e3040d/src/tools.ts#L34-L42

I still lack time/mood to combine matrix + action in one repository as I am still not that deep into the whole container registry push stuff, etc.

This change will introduce BC break to almost any project running infection.

---

We may also need to remove phpdbg, since running phpdbg with pcov installed leads to segfaults.

phpdbg is just an executable while pcov is an extension. I wonder if there is a way to have dedicated phpdbg php.ini which just does not load the pcov extension?

[Ocramius]

I still lack time/mood to combine matrix + action in one repository as I am still not that deep into the whole container registry push stuff, etc.

Same: mostly trying to reduce the dependency upgrade noise caused by PHPUnit 10.

This change will introduce BC break to almost any project running infection.

I will go for 2.0.0 then 👍

phpdbg is just an executable while pcov is an extension. I wonder if there is a way to have dedicated phpdbg php.ini which just does not load the pcov extension?

If we roll 2.0.0 and drop PHPDBG and PHP:<8.0, I think we can get rid of the problem overall: WDYT?