Add support for TCP server APIs

[ryan-summers]

Currently, there is no means to expose a TCP server via the embedded-nal. For example, there is no means to listen() or bind() to a specific port or to accept() connections from clients.

Server operations are added for UDP in #21, but that PR does not address the TCP stack.

One approach would be to refactor TCP similar to UDP:

pub trait TcpClient {
    fn send();
    fn receive();
    fn connect();
    fn close();
}

pub trait TcpServer: TcpClient {
    fn listen();
    fn bind();
    fn accept();
}

This approach would work, but the downside is that the TCP server would be forced to implement the connect() function even when it may never be used by the server.

An alternative approach would be:

pub trait TcpCore {
    fn send();
    fn receive();
    fn close();
}

pub trait TcpClient: TcpCore {
    fn connect();
}

pub trait TcpServer: TcpCore {
    fn listen();
    fn bind();
    fn accept();
}

The downside of approach number 1 is that users may have to implement connect() for a TCP server when it is never used. The downside for approach number 2 is that users will have to implement 2 traits for a client or a server.

I'm curious to hear @jonahd-g and @MathiasKoch 's opinions on this one

[MathiasKoch]

I could live with either, but i think it would make sense to get this in before #28, to get some sort of unification of TCP & UDP?

[jonahd-g]

That's a tough call. While having a separate Core trait is more conceptually "pure", it does come at the cost of additional complexity. I'm leaning towards having only two traits. The UDP traits have the same issue, where the Server necessarily implements a connect method that it will not use. I have a hard time imagining someone wanting to implement the server functionality but not the client. Plus, they could implement connect as a noop pretty easily.

[ryan-summers]

I've been leaning towards @jonahd-g's assessment as well here and opting for the client-server traits as a way to mirror the UDP implementations.