Create Rust version of the "Loggable Data Types" doc section

[abey79]

What

This PR introduces Rust versions of the "Loggable Data Types" documentation section.

Choices I made along the way:

• The primary aim was to stick as much as possible to the Python versions. The output should be the same.
• I've used ndarray for all example (as opposed to, e.g., ImageBuffer for image-related examples).
• I skipped translating image_advanced.py as it primarily focuses various Python packages (Pillow, OpenCV).

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)

PR Build Summary: https://build.rerun.io/pr/2501

Docs preview: https://rerun.io/preview/72885f5/docs
Examples preview: https://rerun.io/preview/72885f5/examples

[abey79]

These examples were exceedingly interesting to write, and are IMHO very useful to identify the shortcomings of the current Rust API. In particular, I ran into the following gotcha, many of which required @teh-cmc's help to sort out:

• RawMesh3D.vertex_colors want packed RGBA u32, but, porting from Python, I first provided a flattened array of u8 RGB components (felt natural since the other fields also take flattened arrays of coordinates/normals/etc.). This would happily compile, but nothing was displayed and no error was presented.
• When implementing the step timeline of the scalar example, I first searched for set_time_sequence (used in Python API) in the Rust docs, which I found in RecordingStream. Turns out it's not in 0.7 and bugged on main (or rather ignored by MsgSender). Again, it compiled and displayed no error, but no timeline was created.
• There is a redundancy between the ClassID key in AnnotationContext.class_map and the ClassDescription.info.id field. It's unclear if they much match, or what's the meaning of each of them. I always matched them and didn't run into any issue, but it's still confusing.
• Likewise for ClassDescription.keypoint_map: the hashmap's KeypointID is redundant with AnnotationInfo.id field and generates confusion.
• Btw, AnnotationInfo.id is u16 but documented as "either ClassID or KeypointID". How un-rusty! :)
• Still on the topic of annotation context, specifically for the "connection" example. To work, the Rust version requires a ClassId(0) splat to be logged with the points, presumably to match the AnnotationContext.class_map hashmap key. Inferring that was possible thanks to classid being listed as secondary component of Point2D/3D, but it was confusing that there appears to be no such equivalent (or hidden default) in the Python API.

[teh-cmc]

This is awesome, cannot wait to make them less painful 😄