refactor: msgs is in fact a queue.
Make hashed queues thread safe.

Each queue now will expose an API to determine if it is full
and also an API to drain all messages from the queue.  This change does
not impact current behaviour and is a step forward towards creating fine
grained locks for lpxc such that we can expose a flush API for the client.
Feature: expose `flush` in API

Lpxc#flush is now thread safe. In order to make it thread safe, we had to
synchronize a mutex inside the method. This meant that we had to remove
the call to flush in Lpxc#puts outside of the mutex in which we initalized the
FlushableLockableSizedQueue. Thus avoiding deadlock.

In addition, this commit removed the external locking in Lpxc#delay_flush
since the flush method is now responsible for such activity.
make a note about how the client will auto-flush
add a test for the Lpxc#flush
Refactor: move full method into flushable queue
refactor: self is superfluous
bugfix: continue processing hash when one queue is empty

This bug has been around for a while now. I suspect that it is rarely the case payloads is nil or empty.
Refactor: use specific data structure

This is more clear as we build a data structure specifically for
our use case.
Refactor: process hash outside of lock

We are replacing the instance of @hash inside the synchronized block
which which decrease the amount of time we need to operate in a shared lock.
move processing into method
Add a more liberal condition for determining LogMsgQueue fullness
Simpler flush implementation for LogMsgQueue
simplify comment regarding flush semantics
Merge pull request #8 from ryandotsmith/flush-api

Expose Flush API