feat: update readers to interact with actfast 1.0.0 interface

[Asanto32]

Resolves #43

Minor changes to readers.py and poetry files for updated package dependencies. Primarily to add support for actfast 1.0.0

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (f338fe7) to head (5a9dfd0).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## development #45 +/- ## ============================================= Coverage 100.00% 100.00% ============================================= Files 4 4 Lines 132 98 -34 ============================================= - Hits 132 98 -34 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ReinderVosDeWael]

Do we need to have separate functions per filetype with the new reader?

[Asanto32]

Do we need to have separate functions per filetype with the new reader?

The underlying naming structure for the dictionary is different, so if we want to move to one function we would still need some sort of logic and different loading for the different Measurements in the WatchData for example

if .gt3x
  ... reading structure for .gt3x
elif .bin (&& format == GeneActiv?)
  ... reading structure for GeneActiv
elif .bin (&& format == some_other _format_in_future)
   ... reading...

[nx10]

• Actfast tells you what format it detected in the "format" field.
• The structure of the outputs is the same - you could search for the specific sensors in all output tables to support all future file format additions

[Asanto32]

• Actfast tells you what format it detected in the "format" field.

Yes, I saw that. So is it better to just have one reader that does

subject1 = actfast.read(file_path)
format_type = subejct1["format"]
if format_type == ....

• The structure of the outputs is the same - you could search for the specific sensors in all output tables to support all future file format additions

But .gt3x doesn't have the ["high_frequency"] and ["low_frequency"], right? It has a unique ["datetime"] for each sensor type (i.e., ["timeseries"][sensor_type]["datetime"/sensor_type], vs .bin that has ["high_frequency"/"low_frequency][sensor_type].

[ReinderVosDeWael]

@nx10 since this change comes largely from the change to actfast, would you mind taking the lead on the review for this PR?

[nx10]

Quickly implemented something over at https://github.com/childmindresearch/wristpy/pull/46