[php-src] PR #24341: Fix in-place URL decoding of interned userinfo in the http and ftp wrappers

Pull Request: https://github.com/php/php-src/pull/24341 Author: alepacheco The http and ftp stream wrappers url-decode the user and password of the parsed URL in place (php_url_decode(ZSTR_VAL(resource->user), ...)), and the http wrapper does the same for user, password and path when it checks a redirect target for control characters. Since the wrappers take a php_uri from uri_parser_class, those components can be interned strings: the WHATWG parser returns one-character usernames and passwords through ZVAL_STRINGL_FAST (the interned single-char strings), and the RFC 3986 parser returns the path / with ZVAL_CHAR. With uri_parser_class => Uri\WhatWg\Url, a redirect to http://+@host/ therefore rewrites the shared "+" string to " "` for the rest of the process (with opcache, in shared memory). This changes the wrappers to never write into php_uri fields: - http_fopen_wrapper.c: the Basic auth header and the redirect control-character check decode into new strings; the relative redirect path is built from the directory part of the current path instead of truncating resource->path in place (same resulting URL as before). - ftp_fopen_wrapper.c: USER/PASS are sent from decoded copies. The new test follows a redirect with a one-character username under the WHATWG parser and checks both the Authorization header sent and that chr(43) is still "+" afterwards. Targeting PHP-8.5, the first branch with uri_parser_class.