Use Arc<[Buffer]> instead of raw Vec<Buffer> in GenericByteViewArray for faster slice

[ShiKaiWi]

Which issue does this PR close?

Close #6408

Rationale for this change

In the GenericByteViewArray, the buffers field is a raw vector, leading to heap allocation when some methods are called, e.g. clone, slice. Using Arc<[Buffer]> instead of the raw Vec<Buffer> can avoid such heap allocation.

And the newly-add benchmark cases about slice shows the improvement:

gc view types all       time:   [687.92 µs 694.54 µs 706.74 µs]
                        change: [+2.9773% +4.3614% +6.3877%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 11 outliers among 100 measurements (11.00%)
  3 (3.00%) high mild
  8 (8.00%) high severe

gc view types slice half
                        time:   [322.61 µs 325.05 µs 327.29 µs]
                        change: [-0.7292% +0.5853% +1.7277%] (p = 0.37 > 0.05)
                        No change in performance detected.
Found 16 outliers among 100 measurements (16.00%)
  14 (14.00%) high mild
  2 (2.00%) high severe

view types slice        time:   [146.78 ns 147.03 ns 147.24 ns]
                        change: [-15.424% -15.106% -14.772%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 23 outliers among 100 measurements (23.00%)
  12 (12.00%) low severe
  4 (4.00%) low mild
  2 (2.00%) high mild
  5 (5.00%) high severe

What changes are included in this PR?

Use Arc<[Buffer]> instead of the raw Vec<Buffer> as the type of buffers field of GenericByteViewArray.

Are there any user-facing changes?

The signature of the method GenericByteViewArray::new_unchecked is changed from:

pub unsafe fn new_unchecked(
        views: ScalarBuffer<u128>,
        buffers: Vec<[Buffer]>,
        nulls: Option<NullBuffer>,
    ) -> Self;

to

pub unsafe fn new_unchecked(
        views: ScalarBuffer<u128>,
        buffers: impl Into<Arc<[Buffer]>>,
        nulls: Option<NullBuffer>,
    ) -> Self;

However, any usage of this method before this PR should still work without any modification.

[tustvold]

Unfortunately the use of impl is still a breaking change as it could impact type inference, e.g if collecting an interator into the argument

[tustvold]

This is also a breaking change

[alamb]

FWIW the reason "breaking change" is important is that it restricts when we can merge this PR:

https://github.com/apache/arrow-rs/blob/master/CONTRIBUTING.md#breaking-changes