Draft: Introduce new DateTime

[fmeringdal]

This PR introduces a custom DateTime that replaces chrono::DateTime<chrono_tz::Tz> and solves a lot of use-cases for us. The problem with chrono::DateTime<chrono_tz::Tz> is that chrono_tz::Tz does not contain a local timezone whereas both DTSTART and UNTIL can be defined in local timezone. Previously we would have to store DTSTART as a DateTime<Utc> even though it was specified in local timezone.

Here is the new DateTime that is able to represent Local times as well:

pub enum DateTime {
    Local(chrono::DateTime<chrono::Local>),
    Tz(chrono::DateTime<chrono_tz::Tz>),
}

It emulates chrono::DateTime by just forwarding every API call to the underlying chrono::DateTime. It also implements From<chrono::DateTIme> so that users can still use chrono::DateTime when setting the starte date, rdate, exdate etc. The big API difference is that iteration result returns this new DateTime rather than chrono::DateTime, but the DateTime can easily be converted to a chrono::DateTime by using the following method DateTime::with_timezone(tz) -> chrono::DateTime.

Fixes #49
Fixes #74

[fmeringdal]

Any thoughts on this API change @omid ?
This change also brings back FromStr and Deserialize to RRule ;)

[omid]

@fmeringdal cool, thanks.
I'm reading it. In the meanwhile, what happened to this idea: #36 (comment) ?

[fmeringdal]

It doesn't quite work for use-cases like the one mentioned in #49 where users want the result to be returned in the same timezone as specified in the rrule string which can only be parsed and known at run time, but generics has to be set at compile time.

[fmeringdal]

Closing this in favour of #79 which in my opinion takes a much better approach.