Make ZonedDateTime parametric on timezone type

[oxinabox]

This is just the parametric type bit from #324 (review)

Contirbutes to #271 once we sort out the timezone types

[oxinabox]

Wow @omus was right, adding a type parameters really does break a lot of things.
It is generally easy enough to be compatible with both but a log ot Vector{ZonedDateTime} need to become Vector{<:ZonedDateTime} (which works with both).

The other thing we should maybe do is add a format versions to the compiled dir file path.
This wouldn't matter for the end user since they would only ever see 1 version since the DEPS_DIR is per version of TimeZones.jl, but for anyone working on it and changing branches. It is a bit annoying

[oxinabox]

We need a promotion rule for different ZonedDateTime{T}s. .
The natural one is to go to the unionall ZonedDateTime, it is what owuld be returned if we were not overriding it in:

TimeZones.jl/src/types/zoneddatetime.jl

Lines 163 to 165 in 906cea0

	function Base.promote_rule(::Type{T}, ::Type{S}) where {T<:TimeType, S<:ZonedDateTime}
	error("no promotion exists for ", T, " and ", S)
	end

Though an alternative might be to all astimezone on all of them, so they all become Variable, or they all become Fixed.
I am not sure on implictaions of that.

but if we don't have a proimotion rule the following happens:

julia> [ZonedDateTime(Date(2000), tz"America/Winnipeg"), ZonedDateTime(Date(2001), tz"UTC")]
ERROR: no promotion exists for ZonedDateTime{VariableTimeZone} and ZonedDateTime{FixedTimeZone}
Stacktrace:
 [1] error(::String, ::Type, ::String, ::Type)
   @ Base ./error.jl:42
 [2] promote_rule(#unused#::Type{ZonedDateTime{VariableTimeZone}}, #unused#::Type{ZonedDateTime{FixedTimeZone}})
   @ TimeZones ~/JuliaEnvs/BidDatabase.jl/dev/TimeZones/src/types/zoneddatetime.jl:162
 [3] promote_type
   @ ./promotion.jl:233 [inlined]
 [4] promote_typeof(x::ZonedDateTime{VariableTimeZone}, xs::ZonedDateTime{FixedTimeZone})
   @ Base ./promotion.jl:272
 [5] vect(::ZonedDateTime{VariableTimeZone}, ::Vararg{Any, N} where N)
   @ Base ./array.jl:126
 [6] top-level scope
   @ REPL[18]:1

[omus]

Though an alternative might be to all astimezone on all of them, so they all become Variable, or they all become Fixed.

I'm definitely against converting the time zones automatically through promotion. I can see having heterogeneous ZonedDateTime types in the same Vector being useful even if it isn't super efficient. I think promoting to ZonedDateTime{TimeZone} seems reasonable.

A similar issue would also exist for: #318

[omus]

Just a thought: what if we introduced a new alternative type to ZonedDateTime? That should allow us to experiment with more breaking changes in a more opt-in manner.

[oxinabox]

My current preferred solution is to introduce UTCZonedDateTime.
It would make the most common case super-lightweight no need to reference timezone at all. and it's the case we can optimise interaction with ZonedDateTimes really well.

[omus]

My current preferred solution is to introduce UTCZonedDateTime.

Relevant: invenia/Intervals.jl#178 (comment)