fix: [OSM-2584] Bump PHP plugin version to fix project scanning

[nico-incubiq]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Bumps the version of the PHP Plugin used by the CLI, which fixes Open Source scanning of PHP projects.
Previously when composer/ composer.phar is available on the machine, the command's result stdout was not handled properly and resulted in [object Object] being parsed as JSON.

Risk is Low as this only affects PHP, which has low traffic and it fixes a bug rather than changing any logic.

Where should the reviewer start?

How should this be manually tested?

• Run the CLI on a directory containing PHP code, making sure that you have composer either installed globally or the composer.phar file in the current working directory.
• This should output scan results as expected, while before this would have crashed with a JSON parsing error

What's the product update that needs to be communicated to CLI users?

Scanning open source dependencies of PHP projects when composer is installed on the user machine works again.

[PeterSchafer]

@nico-incubiq based on the description it appears to me that we don't have any relevant php related test here. Could you please take a look in test/jest/acceptance/snyk-test and see if we can add at least add a happy path test?

[nico-incubiq]

@PeterSchafer interesting point; there is already an acceptance test for this, but it was exercising an overly permissive code path which was hiding the issue (interpreting the error as if we found a [object dependency with version Object]). I've removed this code branch from my PHP plugin bump such that there's only a single code path; so now the existing test properly exercises everything there is to exercise, and a similar error would no longer be hidden.