fix: preserve encoded '+' characters in URL query parameters

[SystemVll]

This is a fix for: #1162

Problem

When processing URL query parameters containing '+' characters (like in dates or mathematical expressions), they were being incorrectly converted to spaces according to standard URL encoding rules. This caused issues with date parameters and other values where literal '+' characters are meaningful.

Solution

Modified the query parameter handling to preserve encoded '+' and replace not encoded '+' by a space.

Impact

• Date parameters with time zone indicators (e.g., "2023-04-05T12:30:00+01:00") now parse correctly
• Mathematical expressions containing '+' operators remain intact
• Any query parameter requiring literal '+' characters now works as expected

[SaltyAom]

Thanks for the pull request, but I would seconded this.

According to HTML 4.01 specification, section 17.13.4.

application/x-www-form-urlencoded
This is the default content type. Forms submitted with this content type must be
encoded as follows:

1. Control names and values are escaped. Space characters are replaced by ‘+’,
   and then reserved characters are escaped as described in [RFC1738]

By default, an HTML form is submitted in an application/x-www-form-urlencoded format, which appends data to query parameters for GET requests.

This means this PR would break an HTML form parsing functionality.

Although RFC 3986 states that pathname should use %20 for space but leave an interpretation for query parameters (if I understood it correctly)

Furthermore, according to the Web Standard implementation of URLSearchParams which treats + as space.

console.log(new URL("https://saltyaom.com?message=hello+world").searchParams.get("message"))
// hello world

This implied that JavaScript developers would likely expect the implementation of URLSearchParams to be the standard.

So I'm likely going to stick with the current implementation of treating + as a space unless there's a solid counter-argument for my reasoning.