Add a second Time implementation using integer times

[spenczar]

It's probably time to really consider this.

This is a parallel implementation, not an instant replacement, because it doesn't use the same column names. We'd migrate everything, and then delete the old coordinates.time.

Some decisions:

• Fixed epoch of MJD. Unix epoch, or JD epoch, or anything else really would have been fine. But MJD is something we're familiar with and can spot unusual values in.
• 64 bits for both days and day-fractions, which is a bit excessive. We could do 32-bit days and still cover ±~6 million years. But I don't know, more range might be good? I'd reconsider it.
• All days are treated as having 86,400 seconds. For a UTC-scaled time, this is not correct; leap second days are off by 1. This affects the calculations of the fractional day part, which is consequential for MJD calculations and astropy conversions. But this is the same behavior as SOFA (so it's the same as in Astropy - so we may never notice it). It's a rare occurrence and the maximum error is 1s.

Not implemented yet:

• Scale conversions; may do this with direct ERFA calls or may do it with astropy, not sure yet, but probably the former (so this would include wip: Directly call erfa from Times to start working around astropy.time #25
• Tests of rounding and equality
• More thorough tests of astropy round-tripping
• Some sort of "round to 64-bit-mjd-precision" function
• Constructor from MJD

[moeyensj]

Defining the precision of a match with an external value is lovely.

[moeyensj]

@spenczar Is there additional functionality you wanted to add before we merge this in?

[spenczar]

The only thing would be astropy-free scale conversions but I don't think that's necessary, we can merge this I think.