force the TimeZone on the custom DateFormat to Settings.getTimeZone() (gh1661)

[brenuart]

Fix for #1661

In summary, the custom DateFormat now has its TimeZone forced to whatever Settings.getTimeZone() will return.
Update test case to reflect the fixed behavior.

This PR does also contain an additional fix for withTimeZone(..) to handle the case where _dateFormat is null (since this is allowed by withDateFormat(..)).

[brenuart]

Now that the DateFormat always has its TZ configured with getTimeZone(), I'm wondering if the settings must still track whether the TZ has been forced or the default should be used.
More precisely:

• is hasExplicitTimeZone() still required? It is public but I doubt anybody uses it...
• having _timeZone initially set to DEFAULT_TIMEZONE and guaranteed to be not null would also reduce the code complexity and risks...

[brenuart]

Ooops - sorry - I just notice I made my changes against master instead of 2.8 - doit it cause problems ?

[cowtowncoder]

The change shouldn't be done against 2.8.

But as to 2.9 -- I'll read the description of the issue, but my thinking so far has been that if user explicitly defines DateFormat, its timezone should be assumed set. However, if further calls for setting/overriding timezone are made, then THAT setting should take effect.
In that sense this sense sounds opposite to current intent, leading to more issues.