Reliable Event Delivery

Good explanation of where this PR leaves us is on the public website: http://www.candlepinproject.org/docs/gutterball/reliable_events.html

Important changes made to EventSource for durable hornetq queues, and preventing duplicate messages that could be caused by server restart. (duplicate messages are still a possibility GB should be prepared for)

Event status added to gutterball, which combines with two phase event processing to hopefully limit the exceptions that could be thrown during event processing, and allow us to identify events that failed later.

Added a super-admin only API call GET /admin/queues to view the HornetQ (not qpid) queues we have configured and a count of the messages pending in each.




> Should we add an ERROR state here for events which could not be processed successfully?

Error state seems to be implied in RECEIVED state. Any event stuck in this state implies that an error happened during event processing. I'd be Ok with either keeping it as is, or changing RECEIVED to ERROR. I don't think we need another state.