Removed array/date handling in .toParams(); made extensible in .toString()

Fixes #31.

@OlivierCuyp and @nickschwab: What do you think of this solution?

`.toParams()` doesn't touch arrays or dates or anything else, for that matter -- it lets something else (the DB driver or user code or whatever) handle value conversions.

`.toString()` has default handling of Boolean, Date, Array, etc, but these can all be easily overwritten (`sql.conversions.Boolean = function(val) { return ... }`). The whole conversion function (`sql.convert`) can also be overwritten -- all the default implementation does is iterate the conversion functions and test with `_.isBoolean()`, `_.isDate()`, `_.isArray()`, etc, to know which conversion function to run.

It turns out that Arrays were added to the SQL standard in SQL-99. I didn't really want to add support for a lot of the stuff added to SQL after SQL-92, since the standard keeps getting bigger, but decided to go ahead & add array support in order to comprehensively support all of Javascript's native types.

Apparently SQL's `TIMESTAMP WITH TIME ZONE` leaves something to be desired (sounds like it can have issues with daylight savings times or political timezone changes or something). I always encourage devs to just use UTC, but there doesn't seem to be a way to explicitly say that a timestamp is in UTC (unless you can specify `+00:00` as the timezone offset? I didn't see anywhere that that was legal, but if it is, I would be sorely tempted to do that instead of using the javascript date object's timezone.) Javascript timezone handling also isn't great, for instance, I couldn't set a timezoneOffset on a date object for the test -- all date objects will always have a timezone offset of the local time.