Use the LMAX Disruptor for the logstash pipeline, rather than queues.

This essentially means that JRuby is now required for running logstash.
The disruptor jar is retrieved from maven in the Makefile,
just like elasticsearch, and other vendors.

The Pipeline class was moved into a new module, along with some other helper classes.

LogStash::Events are pre-allocated in the RingBuffer when the pipeline starts.
As long as the pipeline is running, calling LogStash::Event.new will
retrieve the pre-allocated event from the next available slot in the RingBuffer.
If you call LogStash::Event.new, then you must eventually call either
event.publish or event.cancel, to ensure that the event is returned to the RingBuffer.

Events can no longer be "uncanceled".  The "uncancel" method has been removed.
Events can no longer be "overwritten".  The "overwrite" method has been removed.

Inputs no longer need to take a queue as an argument to their run method.
Instead, they just need to call event.publish, which
will implicitly publish it to the RingBuffer.

For backwards compatibility, if the input takes a queue in its run method,
then a dummy queue will be provided that just calls event.publish when
an event is pushed onto the queue.

Had to modify several filters to publish derived events to the RingBuffer,
and potentially cancel original events (to prevent them from being
processed by other filters/outputs)

Instead of returning new events created, Filter.flush yields to a block
that processes the new events.  The FilterEventHandler will publish those new events.

Filters and Outputs can now optionally take an "end_of_batch" boolean argument
in their execute/filter methods.  When end_of_batch is true, it indicates that
the Disrputor's BatchEventProcessor has reached an end of a batch.
This will allow Filters/Outputs to intelligently process batches.

Changed the spec tests that started the Pipeline to ensure that the Pipeline is shutdown properly.

These changes are mostly backwards compatible with existing Inputs/Filters/Outputs.
The backwards-incompatible changes are:
* If Filters generate new events, they must call 'yield newevent' to ensure the new event is published
* Filters/Outputs can no lenger cache LogStash::Event objects.  They must copy them into some other intermediary data object (usually the encoded form from the codec)
* Filter.flush implementations now must yield newevents, rather than return them.
* Event.overwrite and Event.uncancel methods have been removed.

TODO:
* cleanup
* documentation
* Right now shutdown is not as graceful as I'd like, so will look into this.
* Add more controls to ensure new events are eventually published/canceled
* Would be nice to get output workers to read directly from the RingBuffer, rather than having a separate queue
* Same goes for some threaded inputs writing directly to the ring (e.g. udp)
* Might split filters into their own event handlers
* Need to add an event processor that fires after all other event processors to reset the event, so that memory is freed aggressively.
* Need to do more profiling to determine where current bottlenecks are.  Initial profiling shows performance improvement, but I think there are still areas to improve
* Need to make the Disruptor/RingBuffer more configurable.