WIP connection factory

[fraillt]

After some refactoring has been done, "connection manager" as was proposed here #246 became irrelevant, but instead, a much powerful abstraction became available. This PR proposes a new trait ConnectionFactory, that basically allows a library user to provide its own, connection implementation.

Now all core traits, from bottom-up, looks like this:

• Connection - allows implementing an actual connection, also defines what user events it can receive, and what connection events it can send back to a user. This is a core component that actually is able to send packets and events to the user.
• ConnectionFactory - Defines a Connection type, decides when to accept or discard a connection, and provides conversion from user event to an actual connection address (SocketAddr). It cannot send any packets or events directly, but it can track and change the connection state.
• ConnectionManager - a core component that manages active connections and is generic on DatagramSocket and ConnectionFactory. Types for event channels (used to communicate with a user) depends on a ConnectionFactory type. Current Socket implementation only creates socket and connection factory instance and pass it to ConnectionManager, which provides all the needed functionality.

This PR is a minimum implementation (with some basic DDoS protection implemented in a factory), to start a discussion on how to organize code further so that it would provide convenient and flexible utilities for the user, to write more sophisticated connection implementations.

I suggest this course of action to prepare for multiple connection implementations:

1. create a new folder src/connections/simple and move connection_impl.rs, events.rs, factory_impl.rs, socket.rs->simple.rs, virtual_connection.rs to it.
2. rename Socket to SimpleConnection and add appropriate module definitions so that from the user perspective it could use it like this: use laminar::connections::SimpleConnection;
3. create simple_connection in examples and tests directories and move appropriate files in it.
4. extract useful bits and interfaces from VirtualConnection so other connections could use it as well. E.g. it would be nice to provide a process_incoming/outgoing functions, but with custom StandardHeader implementation.

[fraillt]

After discussion in discord, it was decided that this additional abstraction is not required, because it doesn't solve any direct problems for now.