This new and improved `re_format_arrow` ™️ brings two major
improvements:
- It is now designed to format standard Arrow dataframes (aka chunks or
batches), i.e. a `Schema` and a `Chunk`.
In particular: chunk-level and field-level schema metadata will now be
rendered properly with the rest of the table.
- Tables larger than your terminal will now do their best to fit in,
while making sure to still show just enough data.

E.g. here's an excerpt of a real-world Rerun dataframe from our `helix`
example:
```
cargo r -p rerun-cli --no-default-features --features native_viewer -- print helix.rrd --verbose
```

before (`main`):

![image](https://github.com/rerun-io/rerun/assets/2910679/99169b2a-d972-439d-900a-8f122a4d5ca3)

and after:

![image](https://github.com/rerun-io/rerun/assets/2910679/3fe7acce-d646-4ff2-bfae-eb5073d17741)


---

Part of a PR series to implement our new chunk-based data model on the
client-side (SDKs):
- #6437
- #6438
- #6439
- #6440
- #6441

…6438)

Introduces the new `re_chunk` crate:
> A chunk of Rerun data, encoded using Arrow. Used for logging,
transport, storage and compute.

Specifically, it introduces the `Chunk` type itself, and all methods and
helpers related to sorting.
A `Chunk` is self-describing: it contains all the data _and_ metadata
needed to index it into storage.

There are a lot of things that need to be sorted within a `Chunk`, and
as such we must make sure to keep track of what is or isn't sorted at
all times, to avoid needlessly re-sorting things everytime a chunk
changes hands.
This necessitates a bunch of sanity checking all over the place to make
sure we never end up in undefined states.

`Chunk` is not about transport, it's about providing a nice-to-work with
representation when manipulating a chunk in memory.
Transporting a `Chunk` happens in the next PR.

- Fixes #1981

---

Part of a PR series to implement our new chunk-based data model on the
client-side (SDKs):
- #6437
- #6438
- #6439
- #6440
- #6441

A `TransportChunk` is a `Chunk` that is ready for transport and/or
storage.
It is very cheap to go from `Chunk` to a `TransportChunk` and
vice-versa.

A `TransportChunk` maps 1:1 to a native Arrow `RecordBatch`. It has a
stable ABI, and can be cheaply send across process boundaries.
`arrow2` has no `RecordBatch` type; we will get one once we migrate to
`arrow-rs`.

A `TransportChunk` is self-describing: it contains all the data _and_
metadata needed to index it into storage.

We rely heavily on chunk-level and field-level metadata to communicate
Rerun-specific semantics over the wire, e.g. whether some columns are
already properly sorted.

The Arrow metadata system is fairly limited -- it's all untyped strings
--, but for now that seems good enough. It will be trivial to switch to
something else later, if need be.

- Fixes #1760
- Fixes #1692
- Fixes #3360 
- Fixes #1696

---

Part of a PR series to implement our new chunk-based data model on the
client-side (SDKs):
- #6437
- #6438
- #6439
- #6440
- #6441

Integrate the new chunk batcher in all SDKs, and get rid of the old one.

On the backend, we make sure to deserialize incoming chunks into the old
`DataTable`s, so business can continue as usual.


Although the new batcher has a much more complicated task with all these
sub-splits to manage, it is somehow already more performant than the old
one 🤷‍♂️:
```bash
# this branch
cargo b -p log_benchmark --release && hyperfine --runs 15 './target/release/log_benchmark --benchmarks points3d_many_individual'
Benchmark 1: ./target/release/log_benchmark --benchmarks points3d_many_individual
  Time (mean ± σ):      4.499 s ±  0.117 s    [User: 5.544 s, System: 1.836 s]
  Range (min … max):    4.226 s …  4.640 s    15 runs

# main
cargo b -p log_benchmark --release && hyperfine --runs 15 './target/release/log_benchmark --benchmarks points3d_many_individual'
Benchmark 1: ./target/release/log_benchmark --benchmarks points3d_many_individual
  Time (mean ± σ):      4.407 s ±  0.773 s    [User: 8.423 s, System: 0.880 s]
  Range (min … max):    2.997 s …  6.148 s    15 runs
```
Notice the massive difference in user time.

---

Part of a PR series to implement our new chunk-based data model on the
client-side (SDKs):
- #6437
- #6438
- #6439
- #6440
- #6441