refactor: use trait bound accept fn to reduce duplicate logic

[jdockerty]

This PR is two fold in factoring:

First off, at the moment both TcpProxy and HttpProxy both start, regardless of whether there is anything configured against those listeners. This isn't a huge deal, but it's an easy win to quickly check the provided configuration on startup and simply gate the start of either proxy based on whether that Protocol type actually exists.

Second of it more around general software design. When I initially introduced the Proxy trait in #15 I was thinking about it in the wrong way, whereby I still had the accept function defined within the trait, meaning that there was a tonne of duplicated logic and the same changes being done, just in a different place. Instead, I've now done what I previously hoped and pulled out common functionality, i.e. the accept function has become a trait-bound function, requiring only the implementation-specific details of actually proxying connections to be left to to be filled in by those which satisfy the trait - the reasoning here is that implementations may differ, such as HTTP being concerned with L7 (HTTP method, request path etc.), but the initial acceptance logic should remain the same.