TCK: unknown extensions behavior

Nobody has claimed this yet.

**Challenged tests**
com.sun.ts.tests.websocket.signaturetest.WebSocketSigTestIT.signatureTest()

**TCK Version**
HEAD (likely equivalent to 2.2)

**Description**
The TCK tests that custom extensions can be negotiated, however if an unknown extension is tried to be negotiated in Eclipse Jetty we do not allow it to be sent from the client as no implementation exists (extensions implementations are an Eclipse Jetty websocket-core mechanism which can be added through the service loader). The only extension Eclipse Jetty supports is `permessage-deflate` so any other extensions cannot be requested by the client unless the WebSocketClient knows an implementation for this extension name.

**Additional context**
Either the behavior of not sending an extension that doesn't exist is the behavior we want, or that the TCK clearly state that there are extensions that the implementation of Jakarta WebSocket (eg: Eclipse Jetty TCK code) must implement for the TCK to pass.

Start with the challenged com.sun.ts.tests.websocket.signaturetest.WebSocketSigTestIT.signatureTest() and review how unknown extensions are negotiated by the WebSocketClient. Check the TCK's extension expectations alongside Eclipse Jetty's service-loader implementations; done means the agreed behavior is reflected in the TCK or implementation requirements and the challenged test passes.

Written by the indexing model from the issue text.