Support SOCKS for accessing exposed TCP ports

[RoganDawes]

When exposing TCP ports from a go-http-tunnel client via the server, currently we are required to choose a port on the server to map that port to. e.g server:2222 maps to client:22. However, this does not work well when you have multiple clients all wanting to expose the same client port on the same server port.
The SOCKS protocol allows the client to inform the proxy of the hostname and port that the client wishes to connect to, simply by exposing a single TCP port. Using SOCKS4a or SOCKS5, it is possible to pass the actual hostname to the proxy, rather than allowing the caller to resolve the name to an IP address. In this way, go-http-tunnel can be informed of the hostname and port that the client is attempting to connect to, and can look up the connected client names and ports in the registry to satisfy the request.
This is actually very similar to the existing SNI protocol sniffer method for determining the name that is being requested, but also allows the port to be specified.
For security purposes, the SOCKS protocol also allows for credentials to be passed to authenticate the connection attempt, which could be a valuable additional feature, allowing the go-http-tunnel client to control whether an incoming connection should be permitted or not, which is otherwise not currently possible.
Sample client configuration file might look like:

    server_addr: SERVER_IP:5223
    tunnels:
      webui:
        proto: http
        addr: localhost:8080
        auth: user:password
        host: webui.my-tunnel-host.com
      ssh:
        proto: socks
        addr: 192.168.0.5:22
        remote_addr: ssh.my-tunnel-host:22
        auth: user:password
      tls:
  	proto: sni
  	addr: localhost:443
  	host: tls.my-tunnel-host.com

On the server side, there could be a "-socksAddr" option that specifies the SOCKS port to listen to, disabled by default.

Edited to change the proto: tcp to proto: socks to indicate that the remote_addr should not necessarily be opened as a listening port on the server immediately on client connection, but rather that the socks client should request a connection to that port. Otherwise there is a bit of ambiguity there, especially if the hostname provided actually resolves to an IP address on the tunneld host.

[RoganDawes]

Here is a possible starting point: https://github.com/armon/go-socks5