Introduce Chunk component-level helpers and UnitChunk

[teh-cmc]

This introduces all the usual crazy helpers for when you want to retrieve some very particular piece of data out of a chunk, in one (hopefully) neat, consistent package.

In particular this adds UnitChunk, a wrapper type for Chunk with is guaranteed to only ever hold one row of data, which is going to be very useful when introducing the new Chunk-based latest-at API later on.

• DNM: requires New and improved iteration APIs for Chunks #6989

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 the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!
• If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[jleibs]

which is going to be very useful when introducing the new Chunk-based latest-at API later on.

Interesting -- you're thinking of materializing a LatestAt chunk on-demand for the query results?

[jleibs]

Here, and in all the signatures below, I think we should try to keep result types on the outside as in: ChunkResult<Option<Box<dyn ArrowArray>>>

This seems like it lets us handle serialization errors consistently and then end up with Option<Box<dyn ArrowArray>> inline with:

• Proposal: avoid empty arrays #6602

[teh-cmc]

I had ChunkResult<Option<Box<dyn ArrowArray>>> at the beginning, and it was just as awkward but for different reasons.
In the end I ended up with that variant, but ultimately I don't really have a strong opinion for one or the other.

Two notes, though:

• I purposefully ignored / stayed away from Proposal: avoid empty arrays #6602, as I quickly realized that this PR stream would be complicated enough without attempting to modify our existing semantics. I don't mind revisiting that in the future (and switching the Option<Result>), but for now I don't think this should have any bearing on the current PR.
• I wanted these Chunk APIs to be low-level enough so that more high-level semantics could be built on top of them for the common cases. These high-level APIs are introduced later in this PR stream, at the re_query layer.

[jleibs]

If an missing component array is semantically consider "empty", then a row_index within an empty array should be an error. I'm not sure we need an Option here at all.

[teh-cmc]

Like I commented above: I wanted these APIs to be a lower-level building block. It can be valuable to the caller to know whether the component as a whole is missing with a single API.

Higher-level APIs with the kind of semantics you're describing are introduced later in this PR stream at the re_query layer, and we can decide to treat the missing component as an error there.

[teh-cmc]

which is going to be very useful when introducing the new Chunk-based latest-at API later on.

Interesting -- you're thinking of materializing a LatestAt chunk on-demand for the query results?

(I assume you got your answer while reviewing the next PR!)