Issue: SPR-13551

Issue: SPR-13366

As of Undertow 1.3.0, several APIs have been changed: replacing Xnio's
Pool/Pooled references to Undertow's new ByteBufferPool abstraction.
This move has been made, as part of
https://issues.jboss.org/browse/UNDERTOW-522, to prepare deprecations in
the Xnio API.

This commit adds a new strategy to deal with both 1.0-1.2 and 1.3
Undertow generations.

Issue: SPR-13366

XhrTransport implementations do not need to redeclare interface when extending from AbstractXhrTransport

Xnio 3.4.0 will introduce a new source of ByteBuffers: ByteBufferPool.
Previously this feature was offered by Pooled/Pool/ByteBufferSlicePool;
those classes are now marked as deprecated.

As of 1.3.0.Beta9, Undertow still implements the following method in its
ClientConnection interface, using those deprecated types:

    Pool<ByteBuffer> getBufferPool();

This commit prepares compatibility by suppressing warnings in order to
avoid build failures in our build. Once appropriate changes are made in
Undertow, a specific implementation with new types could be introduced.

Issue: SPR-13366

Before this change, XhrTransport implementations had to be configured
with the headers to use for HTTP requests other than the initial
handshake.

After this change the handshake headers passed to SockJsClient by
default are used for all other HTTP requests related to the SockJS
connection (e.g. info request, xhr send/receive). A property on
SockJsClient allows restricting the headers to use for other HTTP
requests to a subset of the handshake headers.

Issue: SPR-13254

This change adds a new XhrTransport for the SockJs client
implementation. This transport is based on `UndertowClient`,
Undertow's HTTP client.

Note that this transport can be customized with an OptionMap that is
used by the Xnio worker backing the I/O communications (see
http://xnio.jboss.org).

Implementation tested with undertow 1.0.36, 1.1.0.RC3, 1.2.0.Beta1.

Issue: SPR-12008