Remove date limits imposed by Python's datetime module to support BC and far-future dates

[jmurty]

We currently rely on Python's built-in datetime module – and its datetime and date constructs – to represent and return date/time information, but this module only supports dates between 1 and 9999 AD. The in-built Python libraries for handling date/times are simply not designed or intended for representing dates in the distant past such as any BC dates, or dates in the far future.

Currently we ignore "extreme" dates that cannot be handled by datetime by bounding recognised dates to the datetime.MINYEAR (1) and datetime.MAXYEAR (9999) boundary constants.

We will update the date parsing and processing in python-edtf to avoid this limitation by removing any use of the datetime module which imposes the limits, and will use Python's much more flexible struct_time representation when returning values that were previously returned as date or datetime objects.

While this change will make it more awkward to work with some of the API, it will allow us to better represent the real data (rather than bounding the supported date ranges) and should be relatively easy for users to convert into richer Python objects like datetimes when possible (1 AD <= year <= 9999 AD) or something like astropy.time for dates outside datetime's supported range.

WARNING: This change will cause a breaking API change for the following methods of EDTF classes which will return struct_time constructs instead of date or datetime objects:

• lower_strict()
• upper_strict()
• lower_fuzzy()
• upper_fuzzy()
• or indeed any features that rely on the underlying _strict_date() methods

[jmurty]

This work is now merged to master as release 4.0.0