Add secure client IP propagation throughout teleport

[AntonAM]

This PR adds client IP information propagation through teleport infrastructure. It builds upon first stage where signed PROXYv2 headers were added for propagating client IP to the auth server through ALPN (#19008).

Main approach is that we transfer client IP information through reverse tunnel system when we can and then we send signed PROXY header if we have to connect to a server directly. This allows us to only need to send signed headers within single cluster, because we can always transfer IP information in the tunnel between clusters. To make it possible to send IP information through tunnel we add a few new fields to DialReq struct:

// TeleportVersion shows what teleport version is the node that we're trying to dial
TeleportVersion string `json:"teleport_version,omitempty"`

// ClientSrcAddr is the original observed client address, it is used to propagate
// correct client IP through indirect connections inside teleport
ClientSrcAddr string `json:"client_src_addr,omitempty"`

// ClientDstAddr is the original client's destination address, it is used to propagate
// correct client point of contact through indirect connections inside teleport
ClientDstAddr string `json:"client_dst_addr,omitempty"`

We need to know teleport version of the target server, since old versions don't support receiving PROXY headers and would fail.

[strideynet]

Nice work - I've raised a few nits I've picked up on an initial run through, and I'll do a deeper assessment of the actual networking tomorrow.

[espadolini]

It's come to my attention lately that we actually officially support mixing and matching minor/patch versions in the same cluster (as long as everything is at the same major version as the auth), so please doublecheck that an auth server that's not aware of the client IP propagation through the PROXY line will still allow connections in from clients or proxies that are aware.

[rosstimothy]

First pass. Only made it to lib/multiplexer.