Add keypoints dimension to bboxes dataset

[sfmig]

Description

What is this PR

• Bug fix
• Addition of a new feature
• Other

Why is this PR needed?
I noticed we sometimes develop features thinking mostly on the pose datasets, and plan to expand things to bboxes datasets next. A good example is the napari plugin.

If our bboxes and poses datasets were more consistent (or eventually, only one dataset), we would save quite a bit of almost-duplicate work and also potentially reduce cognitive load when planning new features (we wouldn't have to think how things would behave in two different scenarios).

Some options:
1 - One option towards having a unique movement dataset could be to add a "keypoints" dimension to the bounding boxes dataset, that is always set to "centroid". This is what is proposed in this PR (but I have no particular preference, I just wanted to gauge how painful it would be to implement).

2- Another option could be to not impose strict constraints on what dimensions are required to define a movement dataset. We have discussed this before (do we have an issue? I couldn't find it), and allowed this to accommodate the views arrays

Maybe option 1 could be a first step towards unifying the datasets, and then we reduce the constraints on what dimensions are required?

Relatedly, do we see a movement dataset hold both keypoint and bboxes data? For example, with a position_keypoints, a position_bboxes_centroids and a position_bboxes_shapes array. So thinking of bbox data as a set of additional arrays, maybe like we were envisioning for the segmentation masks.

What does this PR do?
Adds a "keypoints" dimension to the bboxes dataset.

References

• Need to re-design dataset validators? #210
• Zulip: Singleton dims

How has this PR been tested?

Tests pass locally and in CI.

Is this a breaking change?

Yes, the bboxes example in particular would need to be reviewed. I will wait until we decide what to do before addressing this.

Does this PR require an update to the documentation?

Yes - the documentation re movement datasets would need to be updated. I will wait until we decide what to do though.

Checklist:

• The code has been tested locally
• Tests have been added to cover all new functionality
• [ - ] The documentation has been updated to reflect any changes
• The code has been formatted with pre-commit

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.84%. Comparing base (9c98037) to head (99b9c91).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #435   +/-   ##
=======================================
  Coverage   99.84%   99.84%           
=======================================
  Files          23       23           
  Lines        1250     1252    +2     
=======================================
+ Hits         1248     1250    +2     
  Misses          2        2           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud