Add polyfill for PDO driver specific sub class constants

[jnoordsij]

As of PHP 8.4, specific subclasses of PDO exist for all drivers, which may contain driver-specific constants and methods if applicable. See also https://wiki.php.net/rfc/pdo_driver_specific_subclasses.

As of PHP 8.5, the driver specific constants and methods available on the base PDO class will be deprecated, to be removed in PHP 9.0. See also https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_driver_specific_pdo_constants_and_methods.

This PR adds a polyfill to expose the constants on the driver-specific child classes for PHP versions prior to PHP 8.4. This allows one to already refer to the 'new' constant, to prevent deprecation errors on PHP 8.5, while retaining backwards compatibility. This can be particularly useful for code requiring support for multiple versions; see e.g. laravel/framework#57141.

Note that no methods have been added in this PR, nor are the classes actually extending the base PDO class yet, with the following reasoning:

• adding the methods only makes sense if the classes are designed in such a way that one will actually construe them in code, as they are class methods
• the recommended way to instantiate the new subclasses in PHP 8.4+ is the new connect static factory method, for which I currently see no way to polyfill; promoting direct construction of subclasses as migration path seems counterproductive to me and the Laravel approach seems to be the neatest way to ensure all new functionality is used on recent PHP versions
• I have not explored if a feature-equivalent implementation can easily be achieved with just extending

This is however opionated and it therefore may still be considered to aim for a more complete polyfill. Note this can also be part of a follow-up effort, rather than as extended goal of this PR.

Edit: second note is that in case clas instatiation is indeed not intended, it might be worthwhile to add a manual constructor throwing some kind of well-chosen exception with well-worded message to better signify this towards consumers of this polyfill.

[jnoordsij]

Note: this is probably 'wrong' and will always be skipped; these constants are only defined when one is not using mysqlnd (see https://github.com/php/php-src/blob/0d4ff662e6d83fd3db0134fc826438307431335a/ext/pdo_mysql/pdo_mysql.stub.php#L22) which seems rare (see also https://www.php.net/manual/en/mysqlinfo.library.choosing.php).

I don't think there's any way to test this, so probably the best way to go here is just drop these or otherwise stick with just some comment as to why these are not tested.

Please let me know what would be the preferable course of action here.

[nicolas-grekas]

Thanks for the PR but this is not a real polyfill and this might create issues on its own.

Checking with \PHP_VERSION_ID >= 80400 should be the way to go here.

[jnoordsij]

I still see some benefit to this, though I do admit in this shape it is not a complete polyfill. As mentioned, I'd be fine with trying to extend this to a "full" polyfill of the respective classes by extending PDO, however then it would be nice to know beforehand if such an effort would be considered to be implemented or not.

[nicolas-grekas]

It would yes, provided the polyfill can be used transparently.