Introduce TCP API

[NikitaNikolaenko]

TODO:

1. Documentation
2. SSL tests (raw ssl, just using the openssl stuff)
3. POSIX tests (currently we only have winapi tests)
4. Combine IPv4 and IPv6 tests (but there's a problem with dazel rn, since it doesn't support IPv6)

[CodingCanuck]

This is a pretty huge review! It's going to be pretty tough to do a solid review on this and keep all of the details in my head at once. That not only will make it tricky to give/receive high quality review feedback with fast turnaround time, but it also increases the chance that this review lasts for a long time which could make it pretty difficult to get through.

Can we think about how to break this up into multiple smaller reviews that we can review and merge incrementally? (Here's a "why" guide for small PRs, but it doesn't touch much on the "how": https://google.github.io/eng-practices/review/developer/small-cls.html )

I haven't dug into this deeply enough to figure out: are there standalone files that can be reviewed independently that we could start with? Or some initial classes or function we could add first?

Context for me as a reviewer: I'm not familiar with the details of TCP, so it's even more valuable than normal to have small/digestible reviews since I'll need an unusual amount of time to gather the domain knowledge I'll need to review this properly.

One quick structural question: I see lots of files starting with the tcp- prefix. Should we instead move these into a tcp folder and drop the prefix (kind of like how we have a grpc folder)?

[CodingCanuck]

(Moving myself off of the action list while we think about ways to break this PR up into more reviewable chunks)

[NikitaNikolaenko]

@benh, I've changed the behavior of our EventLoop. Now it is running asio::io_context inside libuv's uv_loop_t using uv_check_t. This way we can still use EventLoop::Schedule to schedule our eventuals that use asio::io_context.

The only part that I'm not really sure about is the part with uv_unref. Do we even need it?