Document calendar validity ranges

[hsivonen]

It appears that we have five types of calendars:

1. Conversion to/from RataDie uses only integer math. (Gregorian, Buddhist, Japanese, ROC, Ethiopian, Coptic, Indian, tabular Hijri) I think these are valid over i64 RataDie.
2. Conversion to/from RataDie uses floating-point math but has been verified across a large integer range (i32 year?). (Hebrew)
3. Conversion to/from RataDie logically depends on astronomy but we only do integer operations for performance and, therefore, the validity range is limited. And, furthermore, the available floating-point math isn't official enough to guarantee that a local calendar authority would always arrive at the same results far from the present day. (Persian)
4. Conversion to/from RataDie uses a floating-point astronomical simulation, which produces invariant-violating results far away from the present day. And, furthermore, the available floating-point math isn't official enough to guarantee that a local calendar authority would always arrive at the same results far from the present day. (Chinese, Dangi)
5. Reingold's floating-point doesn't work even near the present day, so only an almanac precomputed by an authority works (Umm al-Qura)

The ICU4X documentation for each calendar should state these limits. (Making the limits available via API is intentionally left as a follow-up and out of scope for this issue.) For Chinese and Dangi, it would probably be worthwhile to state two ranges: 1) the range outside of which the calendar invariants are known not to hold and 2) the range that has been verified to match a credible almanac that is independent of Reingold.

Additionally, it would be good to document other less technical validity range information such as the initial adoption of various calendars before which they need to be treated as proleptic.

[hsivonen]

https://ytliu0.github.io/ChineseCalendar/faq.html suggests that the ICU4X Chinese calendar probably isn't historically accurate into the past.

[sffc]

This is closely related to #6970 and I think @Manishearth is the best person to write the proposed documentation.

[Manishearth]

Assessment for 2.1: Does not block milestone since it's docs. Ideally we merge #7123 before releasing.