Add a days iterator for NaiveDate

[gnzlbg]

This PR implements an iter_days() method for NaiveDate that returns an iterator from the current date until MAX_DATE with a step-size of 1 day. It closes #152 .

The Iterator is an ExactSizeIterator because the distance in days from any date until MAX_DATE can be computed in O(1).

Since Step, TrustedLen, and FusedIterator are unstable, I have filled issue #208 to track implementing these as they become stable. The iterator can support them.

To iterate over shorter date ranges users can use .take, .take_while, ... on this iterator.

Once we implement Step for it, users will be able to iterate over weeks by using a step-size of 7 days.

Iterating over months is hard, and this PR explicitly does not address this issue. I've argued in #152 why I think that we shouldn't implement any iterator over months in the library. But if someone wants to discuss that, I've implemented some and could contribute to that discussion (but please open an issue just for that and ping me).

[gnzlbg]

I called the method iter_days but I don't know whether this is a good name. I don't actually like it and would prefer something like just .days() or .days_until_max_date() or similar (.until_end_of_days()? :D ).

[gnzlbg]

@quodlibetor ?

[gnzlbg]

@kennytm ?

[quodlibetor]

@gnzlbg Thanks for this! The iterator is definitely desired, I haven't responded to this because I've been trying to clear up what the chrono API should look like, which has pushed me away from giving this a thorough review.

I do really want this, though, sorry for the delay.

[kennytm]

@gnzlbg Why am I involved? 😅

[gnzlbg]

@quodlibetor I personally like C++'s approach to date and time quite a bit. It has three libraries:

• chrono: clocks, time points, durations, and time units (using compile-time rational numbers)
• date: very fast time-zone unaware date algorithms
• tz: time-zone support

and each library builds on top of the previous one (date builds on chrono, tz builds on date). There were some design mistakes that could be fixed in Rust:

• making minutes use a 64-bit integer instead of a 32-bit integer
• exposing only a system clock and a monotonic clock (no high-resolution clock)

Some literature:

• lots of blog post explaining date and tz's design: https://howardhinnant.github.io/
• chrono papers:
  • http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm
  • http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2498.html
  • http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0092r1.html
• current date and tz proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r5.html

[quodlibetor]

This was merged in #457