[13.x] Normalize HTTP client header values

[GrahamCampbell]

This is needed because Laravel's HTTP client can receive numeric, boolean, existing Illuminate\Support\Stringable, and empty-array header values from its own fluent API before those values reach Guzzle's PSR-7 implementation. Before guzzlehttp/psr7 2.11, scalar and null header values were accepted and cast to strings, and empty arrays were accepted without an immediate failure. In guzzlehttp/psr7 2.11, those compatibility cases started emitting deprecations because guzzlehttp/psr7 3.0 requires header values to already be strings or arrays of strings and rejects empty header arrays.

This change keeps that transition explicit at Laravel's boundary by serializing supported scalar request header values and preserving Laravel's existing Illuminate\Support\Stringable normalization before values are passed to Guzzle, serializing empty header arrays to an empty string for compatibility, and rejecting unsupported header values before lower-level PSR-7 validation sees them. It also applies the same supported header-value normalization to fake response headers before constructing GuzzleHttp\Psr7\Response instances. It does not add native PHP Stringable header support because guzzlehttp/psr7 did not previously accept those objects as header values, and it opens up the ability for a future PR to more easily co-support Guzzle 7, which uses guzzlehttp/psr7 2.x, and Guzzle 8, which uses guzzlehttp/psr7 3.x.

---

There is a similar PR recently merged into the AWS PHP SDK: aws/aws-sdk-php#3289.

[taylorotwell]

Thanks!