SOCKS server life-cycle: detailed definitions and unit tests for onceStarted and onceStopped promises

The general idea here is that the SOCKS server depends on two things to function:

* TCP server
* peerconnection

Once both have successfully started, the SOCKS server is running (`onceStarted`); conversely, once _either_ dies, the SOCKS server has died (`onceStopped`).

This defines `onceStarted` and `onceStopped` reasonably concretely and adds unit tests for how they should behave. Those tests are obviously pretty abstract so this pull request has a number of TODOs marking where integration tests are required, e.g. verify peerconnection's `onceDisconnected` actually fires and that its `stop` method is idempodent.

Tested with the sample apps.

Clearly, a followup pull request would implement a similar lifecycle for SOCKS sessions which depend on both a TCP connection and data channel to function.
When you later open a data channel, it will then make you send another SDP header. I complained about this to WebRTC, but seems to be part of the spec.

Also, I just did some experiments and as it happens, it seems we may need a control data channel in order to know if/when the peer-connection dies (spec needs investigation; see: https://github.com/uProxy/uproxy/issues/408 ).