Refactor tracking data model

[probberechts]

This pull request proposes a new domain model for tracking data and updates various serializers to align with it.

The idea is that a tracking dataset is a collection of object detections. There are two ways to organize this collection:

1. As a sequence of frames where each frame contains the coordinates of all object that were detected at a point in time
2. As a set of trajectories where each trajectory contains the coordinates of a single object over a period of time.

The deserializers still create the frame-based representation but you can now also compute the trajectory-based representation for any trackable object.

Why this is better

I think this has a few advantages:

1. Which representation is most convenient depends on the use case. A frame-based representation allows to analyze player interactions, while a trajectory-based representation allows to analyze a player's kinematics. Now, we allow both representations.
2. Previously we had different attributes and logic for handling ball coordinates and player coordinates. Now both the ball and the ball and players are handled as "trackable objects". It also becomes easier to implement support for tracking other objects (e.g., the referee).
3. I need this for Compute speed and acceleration #298

Breaking changes

• the PlayerData entity was replaced by a Detection entity

Still thinking about

• How can we best support joint tracking data? A subclass of Detection, a Detection.joint_coordinates attribute, ...?
• Maybe Detection is too ambiguous for an entity name? Edit: Now using TrackedObjectState

[UnravelSports]

@probberechts when considering joint tracking I would propose not adding it directly as Detection.joint_coordinates but perhaps as Detection.joints. Where the joints attribute can hold not only the coordinates directly, but perhaps a hierarchical description of the joint connections (perhaps as a graph) and potentially derived values like joint angles, or even inverse kinematics (although this is a bit far fetched).

Additionally, we should probably consider that joint data does not always come in the form of world coordinates, but sometimes it is provided as "angles" (e.g. "head_angle", "hip_angle" etc.) without the inclusion of coordinates.