Further improve C++ logging for many individual log calls by introducing a component type registry

[Wumpf]

What

• Fixes Speed up C++ logging for many individual log calls #4287
• Follow-up to Significantly improve C++ logging performance by using C FFI instead of arrow IPC #4273

As expected, not doing the C++ datatype -> C FFI schema -> Rust datatype roundtrip for each log call helps perf quite a bit, especially when we do a lot of smaller log calls.

The registry a single RwLock protected Vec (we never deregister) which is exposed via a single c entry point.
On the C++ side we use the local static variable mechanism for threadsafe lazy registration (slight codegen adjustment).
Indicator components had some special handling before and were refactored to fit in this system - in the process I made their arrow array shared across all instantiations, further cutting down on per-log work.

---

Benchmark results:

• large point cloud: 0.15s -> 0.14s
• many points: 7.52s -> 4.52s
• large images: 0.57s -> 0.51s

Old values from previous PR. New values are median over three runs, single executable run (this makes more and more of a difference with all these registries!), timings without prepare step, same M1 macbook.

A quick look over the profiler for running log_benchmark points3d_many_individual in isolation tells us that of the actual benchmark running time we spend..

• 35% of the the time in rr_recording_stream_log (of which in turn 20%, so 7% overall, is still arrow FFI translation of the array!!)
• 30% in the various to_data_cell methods
• 10% in exporting arrow arrays to C FFI
• 6% in setting the time
• the rest in various allocations along the way

(taken via Instruments on my Mac)

---

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[jleibs]

This looks great. Nice improvement.