Keypoints kind

Following up below code review comment:

[loud thinking] I am generally in favour of having sv.Detections for all detections-based use cases, but supervision itself seems to diverge from that idea. In the latest release we got new abstraction sv.KeyPoints which do not hold bboxes, and is invariant on "different skeleton for different class" topic - which makes it not 100% suitable for our usage now.
I propose to keep as is for now, but we need to have discussion what to do next - definitely we need support for multiple skeletons (this is in general good change for supervision as this makes the abstraction more robust), but I would say that's suboptimal to loose info about Bounding Boxes when model provides them - maybe we could have both data outputs later in the future - one of Object Detection kind and another of Keypoints kind

Originally posted by @PawelPeczek-Roboflow in https://github.com/roboflow/inference/pull/392#discussion_r1602751208

Start with the linked PR #392 discussion and the referenced supervision/keypoint/core.py implementation. Review how keypoints currently represent bounding boxes and skeletons, then clarify the desired output abstraction and support for multiple skeletons. Done requires an agreed design and a concrete, documented scope before implementation can begin.