switch to libxcrypt implementation when all algo available

[remicollet]

For discussion:

@nikic can you please have a look, some changes coming from you in 7d05bc8

Using libxcrypt could also allow to add more algo, especially yescrypt which mays have interest for password hashing
(also used by pam in some modern linux distro)

[nikic]

Would it make sense to use our own implementation for algorithms we support and fall back to system implementation if we don't? This will avoid behavior differences.

[remicollet]

Would it make sense to use our own implementation for algorithms we support and fall back to system implementation if we don't? This will avoid behavior differences.

Not for "security guys", who prefer using a well known / audited / reviewed implementation ;)

[remicollet]

3rd commit fix the PHP_CRYPT_R_STYLE function in build/php.m4 which was broken and breaks ZTS builds

[remicollet]

seems ext/standard/tests/strings/bug50052.phpt is failing on some libcrypt.so variant... at least the one used in CI... :(

[nikic]

FreeBSD CI has even more failures:

Test DES with invalid fallback [ext/standard/tests/crypt/des_fallback_invalid_salt.phpt]
Official blowfish tests (http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/wrapper.c) [ext/standard/tests/strings/crypt_blowfish.phpt]
crypt() SHA-256 [ext/standard/tests/strings/crypt_sha256.phpt]
crypt() SHA-512 [ext/standard/tests/strings/crypt_sha512.phpt]

This is exactly what I'm concerned about. There are behavior differences between crypt implementations.

[remicollet]

Will work back later on this, perhaps with a new build flag --enable-system-libcryp-yes-I-know-this-may-have-bad-side-effects as at least in work on some distribution (probably the ones using libxcrypt instead of old libcrypt)

At least this allow to find an issue, fixed separately in pr #7582