WIP: http: replace url.parse with WHATWG URL parser

[TimothyGu]

Alternative to #20270. Maintains compatibility in case of e.g. http://xn--1ug.example/, which is not a valid URL but http accepted it anyway.

Also makes urlToOptions safe against any tampering of URL.

This is a WIP; the following parts are not yet done:

• Tests
• Same change in HTTPS

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[jasnell]

hmmm... the wording here I think can be improved.

### DEP00XX: http.request() and http.get() support for invalid URLs

Some previously supported (but strictly invalid) URLs were accepted through the
[`http.request()`][] and [`http.get()`][] APIs because those were accepted by the
legacy `url.parse()` API. The `http.request()` and request APIs now use the WHATWG
URL parser that requires strictly valid URLs. Passing an invalid URL is deprecated
and support will be removed in the future.

I specifically don't want to get in to recommending that users pass the URL object directly into the api as the URL spec itself recommends against that. Let's keep encouraging passing in the URLs as strings and put more attention on the underlying change that is prompting the deprecation.

[jdalton]

Why open this PR while #20270 is still being worked on and not obstructed? 😕

It's kinda like shouting over someone in a conversation.
I'd let the new contributor contribute without pushing past them so soon.

[TimothyGu]

@jdalton As I mentioned in #20270, I had these commits in my branch already even before that PR was opened. Instead of letting these commits go stale I opened a PR so that more people can see it. I do not have time to finish this PR (hence the WIP tag) and have no intention to let this supersede the original PR.

[TimothyGu]

Changes incorporated to #20270. Closing.