Allows to provide custom virtual `net.Dial` and `net.Listen` as an option and use this in transports

Nobody has claimed this yet.

# Context
I want to be able to run Kubo (both listens and dials) over ssh tunnels (`ssh -L`) but without having to do a bunch of manual configuration for addresses and forwards.
A way to do so is to use the [`golang.org/x/crypto/ssh.Client`](https://pkg.go.dev/golang.org/x/crypto/ssh#Client) implementation and do the forwarding in the same binary.

After discussing with @marten-seemann a good way to do this is not to add a bunch of a ssh forwarding code inside `go-libp2p` but just to let consumers provide their own `net.Dial` and `net.Listen` functions.

# How it would look
The two key api points I see changing is first add an option to the entry point package:
```go
// The interface would probably be stored somewhere in core
type Network interface{
Dial(network, address string) (net.Conn, error)
Listen(network, address string) (net.Listener, error)
}

// ProxyNetwork allows to pass an object which will be used for network interactions.
// This default to using net.Dial and net.Listen.
func ProxyNetwork(Network) Option
```
And the *magic* transport constructor would understand and pass this `Network` object, for example the TCP factory signature would look like this:
```go
func NewTCPTransport(upgrader transport.Upgrader, rcmgr network.ResourceManager, net network.Network, opts ...Option) (*TcpTransport, error)
```
And then when it wants a new listener or do a dial it would call this object.
# Done criteria
A consumer can pass a reverse binding object allowing it to supply custom implementations of `net.Dial` and `net.Listen` used to proxy transport traffic.
This object could be used for other traffic (dns resolutions, ...) but I don't care about this for now and I think this should be tracked in an other issue (because this is more refactoring work in many parts of the code).
# Notes
This operates one layer down than transports that operates on other networks like `onion` or [`silverpine`](https://github.com/Jorropo/go-silverpine).
For example if you used an ssh proxy with `onion`, the ssh proxy would be used to contact Tor relays or with `silverpine` the ssh proxy would be used to contact peerings.

Start at the entry point package option and the TCP transport factory described in the issue, then trace where transports create listeners and dial connections. Check how the proposed Network interface would be passed through those entry points. Done means a consumer can supply custom net.Dial and net.Listen implementations for transport traffic.

Written by the indexing model from the issue text.