Install "binutils" in "docker-php-ext-enable" on Debian if "readelf" is missing

[pataar]

On Alpine, docker-php-ext-enable already installs binutils temporarily when the phpize deps are gone (#420), so readelf is available for the zend_extension_entry check. Debian has no equivalent: if a derived image removes binutils (e.g. to drop the build toolchain from a production image), readelf is "not found", the if silently falls through, and every module is written as extension=. For Xdebug that produces a broken config that only surfaces at runtime:

PHP Warning:  Xdebug MUST be loaded as a Zend extension in Unknown on line 0

This mirrors the Alpine behaviour on Debian: when readelf is missing, install binutils for the duration of the script and purge it afterwards. Images that still ship binutils (including all of the images built here) take no new code path.

Tested on php:8.5-fpm (trixie):

• binutils present: no apt calls, output unchanged.
• binutils purged: docker-php-ext-enable xdebug vips uv installs binutils, writes zend_extension=xdebug / extension=vips / extension=uv, all three load, and afterwards binutils is gone again and /var/lib/apt/lists is empty.
• binutils purged, run as a non-root user: fails loudly (apt-get exit 100) instead of silently writing the wrong ini.

[pataar]

The main reason for this change is to reduce the vulnerabilities detected. Many are from binutils. Which is only needed very shortly.

[tianon]

Thanks for the PR! We've intentionally avoided installing and purging apt packages from inside the docker-php-ext-* scripts on Debian (see #438 and #1400): APT has no equivalent of apk --virtual, so it isn't reliably clean.

Re: vulnerabilities, if you're maintaining a derived image, what's in it is yours to manage, and it's reasonable to keep binutils (or reinstall it) until after docker-php-ext-enable runs. We'd rather not carry code that none of our own images exercise, since we won't test or maintain it.

[pataar]

@tianon Makes total sense. Thanks for your time, I'll close this one