We are doing five blades

(c.f. http://www.theonion.com/articles/fuck-everything-were-doing-five-blades,11056/ )

This implements a custom time and date parser based on Postgres' default DateStyle format (currently the only one supported by `pq` anyway). I think this is the only sane way to solve issues like #124.

Cons:

 * not field-tested (I'm willing to run this on a production system for a while, but it largely deals with current timestamps)

Pros:

 * solves a number of issues with existing time parsing code, and paves the way for more fixes (giving us control of our time-parsing destiny)
 * reasonably-well tested
 * the Postgres date formats are pretty stable and are relatively uniform, so flexibility is not a concern

Before merging:

 * should benchmark against current `time.Parse`-based implementation
 * should possibly handle BC dates (i.e., what the zero-value for `time.Time` sometimes ends up at, depending on your time zone, when round-tripped).

I can handle the above if there is some consensus that this is a reasonable approach.

Assumes #127 and #128. Obsolesces #126.

@fdr, this is your fault.