Avoid extra memory access in ArrowByteViewMap

[alamb]

We should avoid this for inlined values (and it's the same as above input_value, so now it does it twice.

Originally posted by @Dandandan in #19975

[Tushar7012]

Hi @Dandandan ,
I have updated the ArrowBytesViewMap implementation to optimize memory access for inlined values and resolve the recent compilation errors:

1. Single-Fetch Optimization: Modified insert_if_new_inner to fetch and convert the input row value to &[u8] exactly once per row. This value is then reused for both hash table lookups and builder insertion, eliminating redundant memory access and byte conversions during hash collisions.
2. API Constraints: CC @Dandandan — I investigated performing direct u128 comparisons for existing entries in the builder. However, GenericByteViewBuilder does not currently expose its internal views buffer publicly. I have used self.builder.get_value(idx) == value_bytes as the optimized fallback, which remains efficient for inlined values.
3. Type Safety & Fixes: Resolved the E0599, E0277, and E0308 compilation errors by correctly leveraging GenericByteViewArray<B> and ensuring consistent byte-slice comparisons.

Verification:
Successfully ran tests for binary_view_map:

• cargo test -p datafusion-physical-expr-common --lib binary_view_map::tests
• Result: 8 passed; 0 failed

[alamb]

BTW the output you are printing looks like it came from an LLM -- please make sure you are following the guidlines here https://datafusion.apache.org/contributor-guide/index.html#ai-assisted-contributions

For example, I am not sure what Type Safety & Fixes: Resolved the E0599, E0277, and E0308 compilation errors by correctly leveraging GenericByteViewArray<B> and ensuring consistent byte-slice comparisons. means and what tests you are referring to as this is an issue, not a PR)