New supportsCustomHeaders property in WebSocketClient interface

[joffrey-bion]

Some WebSocketClient implementations do not support sending custom headers in the handshake, and this cannot be implemented in Krossbow. Here are some cases where it's just not possible right now:

• in the JS browser platform: Support for custom headers for handshake  whatwg/websockets#16
• in SockJS: Sending Authorization Header on handshake? sockjs/sockjs-client#196

Calling connect() with a non-empty headers map on these clients currently causes an IllegalArgumentException. It would be nice to allow consumers to check up front whether the client supports custom headers.

Possible implementations:

• a new property supportsCustomHeaders: Boolean on WebSocketClient
• 2 different WebSocketClient types, one with the connect() method that takes a headers param and one that doesn't.

It would also simplify tests.

[joffrey-bion]

Use different types in generally more appealing, because the API is not "lying" by advertising a headers parameter that is not respected and fails the call.

However, it's not always technically possible to implement different interfaces when the header support of the implementation depends on factors that Krossbow doesn't control. For instance, when wrapping Ktor's web socket, the support depends on the engine, which is not statically known.

We'll have to go the other way: using a property.