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.
Oh, yes, you're right, I was mis-reading. 

So the disadvantage of this style is that it ends up calling close on tcp and peerconnection twice. There was a little work to avoid that before. This is basically a life-cycle design pattern question. Last time I reviewed it, it was better to avoid double closures / know when you do them that you have a problem.  I'm guessing you felt like there was too much work there. I'd suggest we think about abstracting the mutual-close functionality into a generic class actually. We want to do the same thing in rtc-to-net also. 

Probably needs more discussion / a whiteboard session?