Add qpid-cpp-server-store to configure script.

Without this, your exchanges do not persist across qpidd server restarts. The
website indicated this was required but this script missed it.
Add a toString for gutterball event logging.
Allow gutterball message listener to throw exceptions.

An exception encountered here will cause the message to go back onto the queue
and remain there. It will be retried periodically (apparently whenever we
restart the service and rejoin the bus) until it is successful, as we do not
set a time-to-live or expiration.
Allow AMQP bus publisher to re-try failed delivery to bus.

Catching all exceptions here results in the message being acknowledged in
ListenerWrapper, despite not actually delivering the message as we intended.

Instead we allow this method to throw exceptions if something went wrong
delivering to the message bus. The message is then not acknowledged and remains
in the hornetq queue and will be retried.
Major fixes for reliable hornetq message delivery.

Enable durable hornetq queues to store the journal on disk. Previously we were
only in memory so any events that were pending (usually failed and were waiting
to be retried) would be lost.

Set the message ack batch size to 0 to have hornetq immediately acknowledge
every message with the server. Waiting for a batch limit to be reached can
cause duplicate messages if the server goes down and there were acks waiting to
be sent, resulting in those messages being retried on next restart even though
they went out successfully.
Minor logging improvements for HornetqContextListener.
Improved error handling in ListenerWrapper.

Let errors bubble up so events will remain in hornetq to be retried.
Add a /admin/hornetq_journal API call.

Will return an XML export of the current contents of the hornetq journal.
Useful to see if messages are failing to be delivered to the QPID bus.

Super-admin only.
Logging touchups.
Merge branch 'master' into dgoodwin/event-delivery
Fix a broken test.
Drop unused messagetext column.
Store status on event in gutterball.

Events initially are set with status RECEIVED. If it never makes it past this
state, that implies there was some kind of an error, and theoretically the
processing should be retried periodically in the future.

SKIPPED indicates we didn't have a handler for the event target, or we did but
it didn't implement a method for the particular event type for that target.
These too might theretically be re-examined in the future after an application
upgrade if we decided to start processing on some new kind of event.

RECEIVED indicates we did have a handler for the target/type and it was
processed successfully.
Move to two phase event processing in gutterball.

In first phase we try to do only the very basics, read the event JSON, and get
it into our db in it's raw(ish) form, and commit the transaction. Exceptions
should bubble up causing the event to remain in the bus queue.

In second phase we try to do our actual event processing, if applicable.
Exceptions should never bubble up, instead we log them and leave the event in the
db with a state indicating there was an error.
Log the thread ID instead of the request UUID / owner info we don't have in gb.
Fix a transaction error.
Cleanout anything in hornetq queues if deploying with gendb.

If we're wiping the database is stands to reason we don't want anything that
was pending in the hornetq queues to still be sent.
Reduce data sent from GET /admin/queues.

Not much point in dumping the entire queue, instead we'll just report on each
queue and how many messages are pending.
Merge branch 'master' into dgoodwin/event-delivery

Conflicts:
	gutterball/src/main/java/org/candlepin/gutterball/eventhandler/ComplianceHandler.java
Event delivery cleanup.