WIP: client: Initial PacketConn refactoring.

[backkem]

This WIP PR addresses #41. I created it already to get some early feedback. Still TODO:

• [x] Test integration-test
• [ ] Incorporate feedback.
• [ ] Fix test coverage.
• [ ] Update documentation.

High-level overview of changes:

• Refactored the networking of stun.Client around a subset of net.PacketConn.
• stun.Client also implements the PacketConn interface itself to allow layering of the client, E.g.: by turn.Client.
• Made ReadUntilClosed optional. The caller can instead opt to call Client.ReadFrom continuously. This seems like a simple way to enable both multiplexing and handling non-stun messages on the same connection.
• Removed the callback option from Client.Do to create a more natural blocking API.
• Initial scaffolding for supporting multiple transports.
• Added StartTo, IndicateTo and DoTo to allow sending stun transaction to a peer instead of the stun server.
• Refactored the clients under cmd and integration-test. Most clients, especially cmd/stun-traversal, are significantly more straightforward now.
• Tested the clients under cmd.

I'm not entirely happy with having to call HandleTransactions after starting the client in simple use-cases. I'm not sure if there is an obvious way to solve this. In addition, there is an unlikely 'deadlock' scenario in stun-traversal if a non-stun message is received before the response to the binding request. This shows that, while convenient, the blocking API does have some caveats. Lastly, I haven't put much thought into it but this implementation of stun.Client may be usable as a server as well.

[coveralls]

Coverage decreased (-2.3%) to 97.671% when pulling c555e87131671454bc5e9ac605fa1aa3c3f48c5a on backkem:packetconn into ca38c5ce13a5f6315da72b834c6c861ff52be12c on gortc:master.