Implemented error handling pattern in repositories and routes.

In repositories:
Introduced a shared module (common_repository) that exposes functions to
standardize error handling, so we do not need to put error handling
machinery in each repository method. The result is more concise than
explicit error checking machinery, but I feel it is still a bit
complicated, especially the handleQueryResponse function. An alternative
idea might be to introduce a "query" method that would accept the SQL query,
query parameters, and a success callback.

In routes (poems.js):
Introduced "respond" method to standardize on the convention that
unhandled errors result in an HTTP 500 error, and the error details are
logged to the console.
Refactor to module pattern

Now objects are instantiated with a require statement, and dependencies
are passed in to the module's constructor.

The repositories still have to pass the dbConfig into the
common_repository quite a lot, so we could consider converting the
common_repository into an object and inject the dbConfig into its
constructor.
Simplified repositories dramatically

Replaced the 'connect' and 'handleQueryResponse' methods in the
common_repository with a 'query' method that establishes the connection,
performs the query, and manages calling the done() callback. The
repository classes now have to check the err variable, but it's not that
bad because they don't have to worry about calling done(). This feels a
little less weird, and is a lot less code.

Converted the common_repository module into a class, so the dbConfig
object does not need to be passed to every call to query().
Fix bug in top-level error handling.

When an error ocurred, the error was logged to the console but the
response would not return to the browser. Need to call res.send instead of
just calling res.status. res.status does not actually send the response to
the client.
Merge pull request #6 from jimguys/module-refactor

Error Handling & Module Pattern Refactoring