upgrade pg gem to 0.16.0
Bump pg dep
First pass at multi-queue worker.

This change is backwards compatible with previous versions.
The worker takes an optional, ordered list of queues to work.
When looking for jobs to lock, the worker will start from the
first queue in the list and work its way down the list looking for a job.
If no jobs are found in the list of queues, the worker will wait on the
listen/notify chanel of the first queue in the list.

The listen/notify behaviour is not ideal. It would be nice if the worker
could linsten to all the queue channels for which it is interested in.
Remove changlog file. Using GH releases
Worker waits on all queues.

We now issues multiple listen commands so that our worker
will be listening on all queueue LISTEN/NOTIFY channels for
new work.
Merge branch 'priority-worker'
Refactor: remove unused methods

This lib does not use these methods. If a client is calling these
methods, that code should be removed.
Refactor: remove log helper method. without purpose
without purpose
clean up return mechanics
refactor: remove delete class method on queue
Feature: Connection Adapter

The primary motivation behind this feature was to expose a path
for dealing with multiple database connections within a single process.
Specifically, I wanted to test the worker's ability to block on a LISTEN
and subsequently wait when another connection had issued a NOTIFY. This
was not possible with our global Conn module.

This change has introduced a new abstraction known as the ConnAdapter.
The ConnAdapter is explicity set on the Queue. The adapter simply wraps
a few commands around an instance of a PG::Connection. The adapter was also
designed so that clients can pass their active record connections to the
wraper for cases when you want to share a connection between queue_classic
and a rails app.
Bugfix: integrate conn_adapter into the worker

Even if the worker will be responsible for many queues, it should
not maintain a seperate database connection for each queue.
bugfix: Fix unreleased issue with the worker's wait mechanism

This change also provides a correct test for the worker's ability to wait.
Previous test was completely wrong.

cc: @collin
Merge pull request #190 from ryandotsmith/refactorings

Refactorings
fix require statement
version bump v3.0.0beta
readme updates
Currently, QC would not prevent a user from entering a job like

    MyJob.unknown_method.known_method

With this patch, QC `eval`s the whole job description so one doesn't
have to create class methods to run jobs. This makes testing a bit
more easy (`MyJob.new` could receive default arguments) but its main
goal was to avoid cases where a user would create a job `MyJob.a.b`
and `.a` would never be called.

This commit was taken from @franckverrot
fix readme for failed queue updates