Defined Transport for the client

[dgrr]

Solves #972

[dgrr]

Notice that this implementation only works with the HostClient

[erikdubbelboer]

What is the reason for not adding it to Client as well?

[dgrr]

What is the reason for not adding it to Client as well?

I'll in the future, but using the HostClient.Transport, and also I need more time for that. Doing so now in the Client is a little bit problematic. The ideal scenario would be to have something like the Server's NextProtos in the Client. So, on every new connection the HostClient creates, we'll need to check the TLS ALPN fields and if there's any extension for that has been added to fasthttp through a 3rd party library, then put it as TransportFunc.

The main problem is that the Client doesn't own the connections but the HostClient does. And the HTTP/2 lib manages it's own connections, therefore we assume all the Transport implementations are going to manage their own connections. Because at the end, the Transport call should only be used to send requests and get a response back.

As said, I'll try to support Transport in Client, but I'll need more time.

[dgrr]

@erikdubbelboer