Refactor Epoch to keep track of a duration from time scale reference

[ChristopherRabotin]

In a previous version of Hifitime 3.x, the Epoch didn't store the time scale in which it was defined. For that reason, all of the epochs were converted to TAI on initialization.

Now that Epoch stores its timescale, I don't think that the initializers should convert to TAI every time: this adds complexity, and quite frankly, makes it hard to follow what conversions are happening. I believe that confusion is the source of #209.

Switching to defining an epoch as a duration in a given time scale is both simpler code and easier to keep track of the conversions. The downside here is that modifiers (like Modified Julian Dates) will still require the conversion since these modifiers include both another reference epoch and a time scale (unless these modifiers become time scales in their own right?!).

What I'm proposing therefore is the following new definition:

pub struct Epoch {
    pub duration_since_ref: Duration,
    pub time_scale: TimeScale,
}

Another option would be to specify both a time scale and a reference epoch in the Epoch where the time scale is used to convert only the tick rate and reference epoch to align when that tick rate starts. That option seems significantly more complicated though, and most time scales tick at the same rate as TAI/UTC.

@gwbres what do you think?

[ljbade]

I do like this idea, as sometimes you want to store GPS or GAL etc timestamp in a type with an Epoch, and then be able to inspect what the original time scale was later on.

It would be easy to then convert always to something like GPS (or TAI) time scale when needing them all in same timescale for doing calculations.

[ChristopherRabotin]

We started working on it a few months ago here: #241 . I paused the work when I thought that I might have uncovered a bug in the TDB reference epoch... but I'm not sure whether that's the case since the validation tests pass in flying colors and just one of the tests I wrote doesn't (if I remember the status correctly).

I'll pick this up after I release version 0.1 of anise.