Occasionally servers processing HTTP requests will see URLs in the wild which have unescaped hash signs in path and query components. This change allows kj::Url to parse such URLs in the Url::HTTP_REQUEST and Url::HTTP_PROXY_REQUEST contexts.

Our query string encoding function (encodeWwwForm()) was already doing the right thing.

I changed the comment in encodeUriPath() to clarify that it's intended to implement a URL class which stores its path in percent-decoded form, not either/or. I was wrong before.

We'll need more hostname-related code changes in the future, but for now this will solve a Cloudflare customer's existing bug report.

This has the effect of making the authority, path, and fragment components each slightly more permissive in what they don't escape.

The relative URL parser allowed certain hosts which the absolute parser correctly weeded out. This change copies two lines from the absolute parser over to the relative parser.

The main motivation here is to make sure we don't %-escape incoming pluses, but rather interpret them as spaces.