Simplify broker relay by removing message queueing

Previously, the Stomp broker relay employed a queue to store messages
that were sent to it before it had established a connection to the
broker. This scenario could occur as the handling of a client's
CONNECT and sending of a CONNECTED response was performed by
StompProcotoclHandler that is positioned in the pipeline before the
relay.

This scenario has now been simplified by updating the relay to
perform its own CONNECT/CONNECTED handling. The CONNECT frame is
received by the relay and forwarded to the broker. The broker responds
with a CONNECTED frame. The relay then forwards this to the client.
This means that a (well-written) client will not send any messages to
the relay until the relay's connection to the broker has been
established as this is now guaranteed to occur before the client
receives the CONNECTED frame.

StompProtcolHandler has been updated so that its handling of CONNECT
and CONNECTED is off by default. If the simple broker message
handler is being used (rather than the broker relay) the Java config
support will enable StompProtocolHandler's CONNECT and CONNECTED
handling.

The relay's handling of a connection being dropped has also been
improved. When a connection for a client relay session is dropped
an ERROR frame will be sent back to the client. If a connection is
closed as part of a DISCONNECT frame being sent, no ERROR frame
is sent back to the client. When the connection for the system relay
session is dropped, an event is published indicating that the broker
is unavailable. Reactor's TcpClient will then attempt to re-restablish
the connection.
Add heart-beat support to STOMP broker relay

Previously, the STOMP broker relay did not support heart-beats. It sent
0,0 in the heart-beats header for its own CONNECTED message, and set the
heart-beats header to 0,0 when it was forwarding a CONNECTED from from a
client to the broker.

The broker relay now supports heart-beats for the system relay session.
It will send heart-beats at the send interval that's been negotiated
with the broker and will also expect to receive heart-beats at the
receive interval that's been negotiated with the broker. The receive
interval is multiplied by a factor of three to satisfy the STOMP spec's
suggestion of lenience and ActiveMQ 5.8.0's heart-beat behaviour (see
AMQ-4710).

The broker relay also supports heart-beats between clients and the
broker. For any given client's relay session, any heart-beats received
from the client are forwarded on to the broker and any heart-beats
received from the broker are sent back to the client.

Internally, a heart-beat is represented as a Message with a byte array
payload containing the single byte of new line ('\n') character and
'empty' headers. SubscriptionMethodReturnValueHandler has been updated
to default the message type to SimpMessageType.MESSAGE. This eases
the distinction between a heartbeat and a message that's been created
from a return value from application code.