wget: percent-encode control characters and space in the request URL

wget copies the URL path and query into the HTTP request line verbatim, so a
URL that contains a raw CR, LF, or other control byte can split the request
line and inject headers (CVE-2025-60876). A space has the same effect: it
breaks the "METHOD SP request-target SP HTTP/1.1" framing.

The patches proposed earlier on the list reject the whole URL and call
bb_error_msg_and_die. That stops the injection, but it changes behavior. A URL
like http://example.org/foo bar used to be sent (the server gets the literal
space) and now fails outright, because the space is rejected along with the
control characters.

Handle the path and the host differently, matching how GNU wget and curl
behave:

- Path: percent-encode the offending octets in the request-target. Control
  bytes (0x00 through 0x1f), space (0x20), and DEL (0x7f) become %XX. Every
  other byte, including an existing '%', passes through unchanged, so an
  already-encoded path is not double-encoded and http://example.org/foo bar is
  sent as /foo%20bar. CR and LF can no longer reach the request line.

- Host: reject those same bytes. A hostname cannot legitimately contain control
  characters or a space, and percent-encoding is not defined for the authority
  component. This matters in proxy mode: the host is placed in the absolute-form
  request-target and the Host: header but is not resolved locally, so a raw CR
  or LF in the host would otherwise inject. GNU wget (since CVE-2017-6508) and
  curl reject control characters in the host as well.

The change is confined to networking/wget.c and adds one small helper.

Based on the analysis and patches from Takeuchi Yuma (2025-08) and Radoslav
Kolev (2025-11), changed from rejecting the whole URL to encoding the path and
rejecting only the host, to avoid the behavior regression raised in review.

Fixes CVE-2025-60876.

Signed-off-by: Hayden Barnes <hbarnes@herodevs.com>
