`DIO` and `SelectiveDIO` traits, and `DeMux`

[Jonathan de Jong]

#13 gave requirement for something like Connection objects to become fall-through, however, i don't think this works well with the black-box approach.

Furthermore, together with #10, I'd like to make something reusable and generic, so i'll settle with a set of traits, and an object/trait;

• DIO, "Datagram In Out", would also immediately standardise a Datagram IO.
  This'll only be on connection objects for now, but i could possibly look if i can implement this for things like UdpSocket.
  This is only currently meant to signal "upwards" IO, inputs to this will go up an abstraction layer, outputs will go down towards more physical layers.
• SelectiveDIO, basically DIO, but can reject a packet.
• DeMux, i'm not entirely sure if this'll be an object or a trait, but effectively this'll store many SelectiveDIO objects, and try each one in sequence until one of them accepts. This way, a connection object (wrapped in a dynamic selector), or a SRTP sink/buffer, can be multiplexed over the same "path" that a router would select such an object for.

I don't know how well this would work/clash with #9, as partially this is also supposed to solve that bit, where multiple connections can exist over the same peering, but this could be a generic enough solution for now.

For #13, this could be implemented by providing a selector which only checks on the following;
127 < B < 192: forward to RTP
Checking the first byte, and moving on if it doesn't match.

Possibly, in the future, this could allow for a QUIC+DTLS dual endpoint and router.