Localtime using tz-rs

[esheppa]

This is a potential way to solve the CVE-2020-0159. This uses the library tz-rs to read the time zone information file and calculate the local offset from the information contained within.

tz-rs is quite comprehensive as leap second handling has been implemented, however there are some outstanding questions on how to handle this in from_local_datetime (should we assume the local datetime does or doesn't include leap seconds?).

Thanks for contributing to chrono!

• Have you added yourself and the change to the changelog? (Don't worry
  about adding the PR number)
• If this pull request fixes a bug, does it add a test that verifies that
  we can't reintroduce it?

[djc]

Thanks for working on this! I'm not yet sure if this is the right direction, will have to dig into it more.

[esheppa]

Thanks for enabling CI @djc - I'll try and get the CI passing - then I recognize there are a bunch more things to figure out, this is intended as a proof of concept. If this is later decided to be a good solution, I'll go through and add more documentation etc.

Potential issues:

• Minimum supported rust version: This would require some changes to not affect chronos MSRV - but these would be solvable, for example via PR'ing to the timezone file libraries to reduce their MSRV to match that of chrono (or alternatively increasing chronos MSRV, but this may be less preferable)
• Extra dependency: there isn't really any way around this unless the code of a TZif parsing library is vendored into chrono itself.

Other options:

• Providing this integration as a separate crate, potentially alongside removing or altering the Local functionality for unix systems in the main chrono crate.

[x-hgg-x]

For information, I have reduced the MSRV to rustc 1.45 for the version v0.6.6 of tz-rs.

[esheppa]

Thanks @x-hgg-x - I've updated to the latest version of tz-rs

[djc]

Thanks for working on this! Unfortunately, I'm inclined to take a different direction, see #677. Would be happy to get your feedback.

[esheppa]

Thanks @djc - I'll close this and leave some comments on #677.