Add support for HTTP1 communications to the Networking API

[Duckwhale]

Goals:

• [ ] Can perform HTTP requests (via a new HttpClient module) on top of the existing TcpClient implementation
• [ ] Can create HTTP servers (via a new HttpServer module) on top of the existing TcpServer implementation
• [ ] Spec compliance is tested for the latest HTTP/1.1 RFCs
  • [ ] RFC 9110: HTTP Semantics
  • [ ] RFC 9112: HTTP/1.1

Roadmap:

• [ ] Prerequisite: #168
• [ ] Compile a list of test cases required to ascertain RFC-compliance
• [ ] Implement the necessary abstractions to run the tests without too much verbosity/manual busywork
• [ ] Implement test cases
• [ ] Implement HTTP client module
• [ ] Implement HTTP server module

Non-goals:

• [ ] TLS/HTTPS support (separate issue)
• [ ] Streaming APIs (required for large files): Buffering is easier to use and sufficient for now, the rest can be built on top
• [ ] Caching (RFC 9111): Not really necessary, nginx/apache are likely better solutions where this is needed

[Duckwhale]

This is just to formalize the requirements after building a couple of different prototypes. Requires #90 (mostly done, needs cleanup).

As for performance, I am using llhttp-native-c and llhttp-ffi as the maximum (both 1 GB/s on my desktop) and luvit (pure Lua, measured at 20-25 MB/s on the same machine) as the minimum. It is clear that the requirement of providing a user-friendly API is directly at odds with reducing overhead, and a streaming API on top of that will also be less user-friendly by default.

For this issue, I will limit the scope to a basic, buffering and somewhat inefficient implementation that is sufficient to proceed with the WebSocket protocol support. Streaming can be performed by simply overriding the event handlers (and then creating async write requests via libuv), while reducing the memory footprint is possible by disabling the FFI layer's event buffering (which comes with other drawbacks). I doubt there's a perfect solution, or even one that fulfills most of the requirements, here.

[Duckwhale]

Blocked by #168, since hacking in the URL parsing logic required for some of the RFC specs doesn't seem like a good idea.