[2.8] Encode plus sign in withQueryValue() and withQueryValues()

[eyupcanakman]

Uri::withQueryValue() and Uri::withQueryValues() do not percent-encode +
in keys or values. Most HTTP servers interpret an unencoded + in a query
string as a space (per the application/x-www-form-urlencoded convention),
which corrupts values that contain literal plus signs.

+ is a sub-delimiter under RFC 3986, so filterQueryAndFragment() lets it
through. But Query::build() already encodes + to %2B via rawurlencode().
The fix adds '+' => '%2B' to QUERY_SEPARATORS_REPLACEMENT so both code
paths produce the same output.

Added a test covering + in keys, values, and alongside spaces.

Fixes #618.

[edegaudenzi]

Thank you @eyupcanakman for your fix proposal and for making sure all the tests correctly pass; after so much time things are moving forward.

My twopence contribution: I've been using a custom modified version of Guzzle - with your very proposed fix - in a production environment since I first opened the issue in Nov 15, 2024.
Knowing I am not "the world" and the Guzzle I've been using was restricted to the use within a REST APIs context, I can confirm in my case it didn't cause any issues since then.

There is only one additional descriptive text you may want to put in your PR: in the \GuzzleHttp\Psr7\Uri::generateQueryString() comments, there is a mention - Query string separators ("=", "&") within the key....
With your change, also the symbol + should be added there to the list.

I think it's maintainability-safe to just add in the + in the comments because + was the last missing bit to fully support RFC3986; in the standard there are not other symbols left to this encoding topic.

[eyupcanakman]

@edegaudenzi Thanks for testing it out. Good catch on the docblock. I'll add the + to the comment in generateQueryString() and push the update.