Potential Optimization for interleave/take on RunEndEncoded arrays

[alamb]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
on #7671 (comment), @brancz points out

It actually throws up a larger design question: Should two extend calls, that end up referencing the same value even continue the "previous" run? As in if we an array that is an REE with the logical values being:

[1, 1, 0, 0, 1, 1]

and the interactions are

arr.extend(0, 2)
arr.extend(4, 6)

should the result be

1. runs: [4], values: [1]
2. runs: [2, 4], values: [1, 1]

Obviously 1) is more optimized, but it would also mean that .extend needs to be able to compare arbitrary values (because it needs to know when to continue vs. start a new run)

Describe the solution you'd like
Consider implementing this optimization

Describe alternatives you've considered

Additional context

[Rich-T-kid]

take

[alamb]

It turns out that coalescing REE runs requires comparisions which takes a big deoendency on arrow-ord as @Rich-T-kid has discovered in

• Combine overlapping runs in REE (take kernel) #9865

I am not sure the tradeoff of larger binary size for all users of Arrow is worth it without a more realistic use case 🤔