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

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

This is a fork of the old `DataTable` batcher, and works very similarly.

Like before, this batcher will micro-batch using both space and time
thresholds.
There are two main differences:
- This batcher maintains a dataframe per-entity, as opposed to the old
one which worked globally.
- Once a threshold is reached, this batcher further splits the incoming
batch in order to fulfill these invariants:
  ```rust
  /// In particular, a [`Chunk`] cannot:
  /// * contain data for more than one entity path
  /// * contain rows with different sets of timelines
  /// * use more than one datatype for a given component
/// * contain more rows than a pre-configured threshold if one or more
timelines are unsorted
  ```

Most of the code is the same, the real interesting piece is
`PendingRow::many_into_chunks`, as well as the newly added tests.

- Fixes #4431

---

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