Rework the performance tests

Previously, the tests would ultimately deliver all the messages to
a channel that held them in a queue. I could not get the tests to
run as they would run out of memory as this queue filled up.

I have reworked the tests to use a single channel with a single
handler. This handler decrements a latch. The latch is used to
track when all the messages have been handled. The handler is
configured using a ConsumerEndpointFactoryBean to make the dispatching
of the message to the handler as efficient as possible.

The tests using Spring's task executor had a reject policy of
CLIENT_RUNS configured. This was causing a lot of the messages to
be delivered by the sending thread as its queue quickly filled up.
This isn't an apples-to-apples comparison as (other than
DirectChannel) all the other approaches will guarantee that the
message is delivered on a different thread. To bring things closer to
being apples-to-apples I have reconfigured the task executor to use
an unbounded queue and removed the reject policy.

Each test variant is run 10 times and the throughput that's output is
the average throughput across the 10 iterations.

Three variants of each test are run:
 - Sending the same message each time
 - Sending a new message each time
 - Sending a new message each time using a custom id generator

The id generator used by the 3rd option simply increments an atomic
long to get the longs for the high and low portions of the UUID.

RingBufferChannel has been changed to implements SmartLifecycle
rather than just Lifecycle. This change was necessary to get its
start and stop methods to be driven.

The results from running on my iMac can be found in the README. I
currently don't understand the performance of the reactor ring
buffer dispatcher which is slower when resending the same message
vs sending a new message using a custom id generator each time.