Try both long-polling and websocket transports in case of failure

[nicofff]

Is your feature request related to a problem? Please describe.
We have a pretty big websocket footprint in our product, and we've discovered that, by themselves neither transport offers 100% connection success rate for our users.
We had some issues earlier in the year with the cookie based sticky sessions needed to have a successful long-polling handshake. It was breaking when our product was used in some 3rd party site with iframes due to 3rd party cookie restrictions. We found that a significant number of clients in our space have the browser cookie settings set to block all 3rd party cookies by default.
We made the switch to use the websockets transport by default, and while we solved that case, we discovered that some client couldn't connect due to proxy configuration settings on their networks messing with websockets.

I understand that these issues fall into "client misconfiguration" territory, but the fact that there is no attempt to connect through websockets if long-polling fails under the default configuration (or any available configuration that we are aware) means that we are in a position where we are forced to choose between the failure rate of long-polling on it's own, or websockets on it's own.
The ideal scenario would be that socket.io-client would try one transport first, and if that fails it would try the other one, and only fail if the connection couldn't be established either way.

Describe the solution you'd like
There would be a way to configure the client to try both methods and only give up if both of them failed.

Describe alternatives you've considered
We can always do this manually. Try with the default config, and if that fails try only with websockets (or the other way around). We are probably going to go this route while this (hopefully) gets implemented.