Make Transform3D always log all its components

[Wumpf]

• logging e.g. just a translation should log empty arrays for all other transform components
  • This effectively implements Allow archetypes to clear and/or update existing components #3381 partially for Tranforms
• bring back IDENTITY == empty transform which allows you to override a previous transform archetype

Why is this important? Example:

• log just a translation (via Transform3D archetypes)
• log just a rotation (via Transform3D archetypes) -> Is the translation still there? We think it shouldn't be

[emilk]

This will add noise to the UI, and also add some logging CPU overhead, but I suggest we wait with fixing both those problems until we tackle all of #3381

[emilk]

An alternative approach to this is to do a special query when querying transforms. It would go something like this:

• Query all transform components (Translation3D, RotationAxisAngle, RotationQuat, Scale3D, TransformMat3x3).
• Find the latest RowId of all of them.
• Ignore all components with a different RowId.

This would means each new log call of any of these transforms would effectively reset the other ones.

The advantage of this idea is that we don't have to do the work in this PR (always log all components to reset any previously logged one).

However, it is a special snow-flake querying model, just for Transform. I would need to be implemented in multiple places (transform hierarchy, selection view, table view, …) and be explained to the user

We also want to support logging transform components without using the Transform3D archetype.
For instance, a user should realistically be able to do this:

rr.log("planet", rr.Position3D(…));
rr.log("planet", rr.Colors(…));
rr.log("planet", rr.Translation3D(…));
rr.log("planet", rr.Rotation3D(…));

It would be surprising to the user if the translation was ignored in the viewer.

There are more advanced queries that could solve this, e.g. "if the transform components are non-overlapping (like translation and rotation), then still use both…" but this now becomes a complex decision tree that again needs to be replicated and explained to users.

In contrast, the approach argued by this PR:

• Supports component-wise logging
• Has no special handling in the viewer
• Is on the road towards Allow archetypes to clear and/or update existing components #3381, where we want to go with all archetypes eventually