Add pose reader classes supporting ingestion of SLEAP tracking data

[jkbhagatio]

A draft of the reader for

SainsburyWellcomeCentre/aeon_experiments#241

[ttngu207]

One potential change to the Sleaper reader class is to remove the requirement of model_path as an argument to instantiate the class.
Instead, this model_path can be specified upload loading the data.

I will review and potentially propose a modification to the current solution.

[ttngu207]

We discussed the possibility of the reader not needing the model path. The model path can be extracted from some meta information somewhere.
This model path information is stored anyway, perhaps better yet that we store a timestamp and the model path as event, for each time the model is changed.

[glopesdev]

@ttngu207 @jkbhagatio @lochhh today we were discussing file name conventions for binary SLEAP acquisition files, and we are currently leaning towards simply using the relative model path as an identifier suffix: <hpc_node_used_for_training>_<job_id>_<training_completed_time>_<model_type>

An example file name would be: CameraTop_SLEAP_ENC1_9834659_20230307_TailTattoo_2023-08-10T14-08-00.bin

Even though it feels long, we were comparing it with other alternatives such as assigning a GUID to each trained model and it wouldn't be much different: CameraTop_SLEAP_C9A139B9-E3DE-4FAC-BFFA-2421B2E5F621.bin

The former is arguably much more readable and ammenable to wildcard glob search, e.g. searching for all tracking data of <model_type> and hpc_node would be CameraTop_SLEAP_ENC1_*_TailTattoo_*

[jkbhagatio]

Given the above, we assume that model metadata config file lives next to the model?

@glopesdev also if we go with the dataframe columns being:

class | class_conf | part | part_conf | x | y

will need to slightly change this reader's read() method to output in this format

[jkbhagatio]

Hi all, there should be a working version of this now, via the Pose reader.

It should work with the example files in '/ceph/aeon/aeon/data/processed/test-enc1...'

We should add a proper test for this (and other readers), and decide where it will finally live (see #226), but this provides a working solution for now.

[glopesdev]

Looks great, just have a few comments to look into before merging. I think most of them can be left for when we decide to move this reader into the core io module, but some could be nice to do right now.

[glopesdev]

A few more optimization and formatting questions, but otherwise looks good!

[glopesdev]

Looks good, just left some final comments for consideration and I think the refactoring of tests should be left to another PR, since they seem to be unrelated to testing this reader and possibly more related to the #228 PR.

[glopesdev]

Can we keep this refactoring of the tests outside of this PR? I am happy discussing and refactoring the standard imports as we discussed on #238 but would make it easier to keep track of changes if that was done in a separate PR.

[jkbhagatio]

Looks good, just left some final comments for consideration and I think the refactoring of tests should be left to another PR, since they seem to be unrelated to testing this reader and possibly more related to the #228 PR.

@glopesdev Sounds good, read all of your most recent replies/suggestions here and agree with them all - will do them all before merging, and move the tests to #228