Better support of times & timezones

- use `LocalDateTime` instead of `DateTime' for client facing timestamps.  these values are just a timestamp without any timezone (conference fields: registration start & end times, event start & end times, early registration cutoff
- upgrade to latest sql2o version which adds support for `LocalDateTime`
- use separate Json serializers for `DateTime` and `LocalDateTime`
Is that just to reap the benefits of `DateTimeZone`?  It feels like a fair bit of add'l overhead, would it be justified by the the benefits?  Could we get burned if we don't use their class?