In vortex-data#4946, we forced rebuilding ListView arrays that were being built.

A user report came in with a 10x performance regression with lots of
time being spent inside of ZSTD decompression. On further investigation,
the flame graph clarified that inside of a file scan, we were filtering
a ListView array, where the elements were ZSTD compressed. Calling
`naive_rebuild` goes through an awful `append_scalar` pathway, and
`scalar_at` for ZSTD...decompresses a whole frame.

To avoid this, we fully canonicalize the elements, offsets, and sizes in
bulk, then stitch a new ListView from the components.

This is 10-20x faster than the previous codepath, per the added
benchmark.


Before:

```
Timer precision: 41 ns
listview_rebuild  fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ rebuild_naive  1.821 ms      │ 2.535 ms      │ 2.019 ms      │ 2.024 ms      │ 100     │ 100
```

After:

```
Timer precision: 41 ns
listview_rebuild  fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ rebuild_naive  109.5 µs      │ 192.2 µs      │ 121.1 µs      │ 122 µs        │ 100     │ 100
```

---------

Signed-off-by: Andrew Duffy <[email protected]>