support qzss time scale

[gwbres]

Introduces QZSS time scale, which is straight forward in the sense it behaves like GPST strictly, but comes from a set of dedicated clocks.

Partial answer to issue #210

[codecov]

Codecov Report

Patch coverage: 90.47% and project coverage change: +0.63 🎉

Comparison is base (692b222) 80.46% compared to head (4d0f6f0) 81.09%.

Additional details and impacted files

@@              Coverage Diff              @@
##           4.0.0-dev     #228      +/-   ##
=============================================
+ Coverage      80.46%   81.09%   +0.63%     
=============================================
  Files             16       16              
  Lines           3731     3783      +52     
=============================================
+ Hits            3002     3068      +66     
+ Misses           729      715      -14     

Impacted Files	Coverage Δ
src/asn1der.rs	84.04% <75.00%> (+0.34%)	⬆️
src/timescale.rs	97.43% <90.00%> (+2.94%)	⬆️
src/epoch.rs	89.05% <91.83%> (+1.06%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ChristopherRabotin]

Woohoo ! Great, thanks, I plan to pick up hifitime this week so I'll have a look soon. I changed the merge branch to 4.0.0-dev which will be the development branch for version 4.0.0. There are about 400 downloads of hifitime per day now, so I don't want to introduce breaking changes on the version 3.x releases.

[gwbres]

Hello Chris,
it picked up a few lines that are not covered by a test case, i'll submit that tomorrow i'm heading to bed right now :)
see you

[gwbres]

@ChristopherRabotin ,

I forgot to increment a loop in a testbench somewhere.
These loops iterate from 0.. to N , where N is the highest integer number representing the "latest GNSS" system known by this library.
This is easy to forget since we don't have a macro to figure this number out easily (previously 7, now incremented to 8).

But that triggers src/asn1der::test_encdec correctly now which says a QZSS timescale was not preserved through the test.
Obviously, the problem comes from what happens in Epoch::from_der[u8 buffer] but I have no idea what function this inherited feature relies on.
Currently, all Integer or Str interpretation are properly coded IMO.

[Edit]
Well, the answer was kind of simple.
I had matched GPST and QZSST in all duration calculations (to and from), since they're identical.
But in some of these operartions we fix a timescale, and it has to be "independent" now.
So it's easier to provide dedicated methods like any other timescale, but unfortunately the code quantity keeps growing.
In the end, it's a whole new set of to_, from_ and python constructors

[ChristopherRabotin]

Great! #210 (comment)