Rename `LeafTransform3D` to `InstancePose3D` & disable its implicit clearing again

[Wumpf]

On the implicit clearing issue

Context

We very recently made it so that logging any Transform3D or LeafTransform3D would always log all its components, thus clearing everything that you haven't set. The prime motivation for this was backwards compatibility: In 0.17 and older, there's a single component whereas in 0.18+ there's many individual, meaning that logging a translation now wouldn't override a previously logged rotation, wheras it did before.

This works out fine for the most part, but we also introduced LeafTransform3D (as a replacement for OutOfTreeTransform3D + more general use) and replaced the Position3D/Rotation3D (old union) components of Boxes3D (and, new, Ellipsoids3D) with LeafTranslation3D/LeafRotationQuat/LeafRotationAxisAngle. This causes this code:

        rr.log(
            f"world/annotations/box-{uid}-{label}",
            rr.Boxes3D(
                half_sizes=half_size,
                centers=centroid,
                labels=label,
            ),
            rr.LeafTransforms3D(mat3x3=mat3x3),
            static=True,
        )

To log a warning because it has overlapping components as it overrides the centers with empty array. Logging one after the other would do so silently!

Solution

We explored various variants of duplicating the components further, which would presumably be easier with tagged components. Even not considering todays type explosion, this approach has the drawback of adding another layer of transforms that has to be stacked and named correctly: Transform3D -> LeafTransform3D -> Box/Ellipsoid Transform components (as part of this discussion we touched on how "pure" transform representation should be - in the limit all boxes can be unit boxes that are just transformed, but while correct we arrived at a sense of alienating too many users with the more extreme models)

Instead, we decided to stick with component sharing as-is, but disable implicit clearing on the new (!) LeafTransform3D again.

On naming

To further drive home that the transforms are about the pose of an object, we decided to rename LeafTransform3D to InstancePose3D, with the associated components following the PoseX pattern, e.g. PoseTranslation

Advantages:

• expresses that this is outside of the transform hierarchy and about concrete instances
  • note that these are practically entity<-instance transforms! The TransformContext code already handles them like that
• the instancing behavior we have now on Mesh3D/Asset3D/Boxes3D/Ellipsoids3D becomes much more apparent
  • this gives an easier way forward to how instancing should be supported by various visualizers. E.g. "point cloud instancing" would make much more sense now in thus far that we can talk and think about it in this way ("this visualizer supports instancing")

[Wumpf]

via @nikolausWest ":+1: but mention "instancing" somewhere in the docs so it shows up" e.g.: "you can achieve mesh instancing [..]"