Add a URL module to implement standardized URL processing for HTTP request targets

[Duckwhale]

Can probably port the one from NodeJS: https://nodejs.org/api/url.html#the-whatwg-url-api

Source: https://github.com/nodejs/node/blob/v19.3.0/lib/url.js

Some of the more esoteric features (internationalization) may not be very useful here. I'm mostly interested in the test cases, really.

Roadmap:

• [ ] Port the existing test cases from NodeJS
• [ ] Port the NodeJS implementation
• [ ] Streamline interfaces where necessary (should be idiomatic)

---

Required for #137

[Duckwhale]

After looking at the NodeJS code, it seems that porting their WHATWG URL module directly might be more trouble than it's worth:

• Their test suite for the new URL API is basically just comparing the URL constructor against the web platform test data
• There's some (very few) additional tests, which may or may not be worth porting as well
• The implementation uses their (separately-tested) legacy URL module for many things
• In typical NodeJS fashion, this implementation is rather messy and likely difficult to port (if that even is desirable...)
• JavaScript also uses UTF16 and the test data (being JSON) appears to be encoded such that it would have to be transformed

All in all, this will be more work than originally anticipated. Instead, there may be some alternatives worth considering:

• Port the somewhat simpler, but equally-JS specific implementation at https://github.com/jsdom/whatwg-url
• Reimplement the required logic (basic URL parser etc.) based on the rather detailed spec and skip all JS-specific parts
• Use a native library, with glue code where needed
  • https://github.com/cpp-netlib/url (need to create a C API wrapper, and FFI layer)
  • https://github.com/uriparser/uriparser (need to create a FFI layer)
  • https://curl.se/libcurl/c/libcurl-url.html (overkill, needs FFI layer)

Lastly, I wonder how important having this module right now actually is. I want to get to WebSockets ASAP and having some basic HTTP functionality, just enough to complete the handshake really, might be enough even if the implementation isn't a fully spec-compliant HTTP server (or client, for that matter). So, perhaps shelving this until later is the better approach here.