Use TimeZone in DeserializationContext when SerializationFeature.WRITE_DATES_WITH_ZONE_ID is not set

[islanderman]

Outline

This pull request is to fix #68. It adds a feature to honor TimeZone in DeserializationContext if SerializationFeature.WRITE_DATES_WITH_ZONE_ID is not set.

If timezone format is specified as part of JacksonJodaDateFormat during init time, it will be honored first; otherwise TimeZone in DeserializationContext is used.

I realize this means if JacksonJodaDateFormat is predefined as in constructor/@JsonFormat, TimeZone in DeserializationContext is going to be invalid. However this TimeZone has a default value as . So that there's no way of distinguishing if this is just a default or this TimeZone should be handled specifically.

Fix

There are only three datatypes that are associated with TimeZone:

1. DateTime
2. Interval
3. DateMidnight

DateTimeZone tz = _format.isTimezoneExplicit() ? 
    _format.getTimeZone() : DateTimeZone.forTimeZone(ctxt.getTimeZone());

---

Also add additional unit test cases for TimeZone related features.

[cowtowncoder]

Looks good to me, will be happy to merge this in.

At this point we do need the Contributor License Agreemant (from https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf) to merge the fix. It's a one-time thing, good for any further contributions.
The usual way is to download, print, fill+sign, scan, email to info at fasterxml dot com. If so, we'll archive CLA, and I can proceed with merging right away.

[islanderman]

Done. Please merge when you have time. Thanks.