IN LIST: add UInt16 bitmap filter

[geoffreyclaude]

Which issue does this PR close?

• Part of Further improve performance of IN list evaluation #19241.
• Stacked on IN LIST: add UInt8 bitmap filter #23011.
• Next in stack: IN LIST: unify bitmap filter implementations #23035.
• Extracted from Optimize IN performance with specialized implementations #19390.

Rationale for this change

#23011 uses a bitmap checklist for UInt8, where there are 256 possible values. UInt16 is the same idea with a larger value range: 0 through 65,535.

That is still small enough to represent directly. A UInt16 bitmap needs one bit for each possible value:

• 65,536 possible values
• 65,536 bits total
• 8 KB of memory

Then a lookup is still simple: use the input value as the bit position and check whether that bit is set. For example, if the list contains 42, bit 42 is set, and every input row with value 42 can be recognized with one bit test.

This PR keeps the scope narrow: it adds the unsigned 2-byte bitmap path as a concrete UInt16 filter. #23035 then unifies the UInt8 and UInt16 implementations, and #23013 uses that shared shape for signed same-width reinterpretation.

What changes are included in this PR?

• Adds UInt16BitmapFilter, backed by a heap-allocated 65,536-bit bitmap.
• Routes UInt16 constant-list filtering to that bitmap path.
• Keeps the same IN / NOT IN null behavior as the generic path.
• Adds focused coverage for UInt16 boundary values, nulls, and NOT IN.

Are these changes tested?

Yes.

• cargo fmt --all
• cargo test -p datafusion-physical-expr bitmap_filter_u16 --lib
• cargo test -p datafusion-physical-expr in_list_int_types --lib
• cargo test -p datafusion-physical-expr test_in_list_from_array_type_combinations --lib
• cargo test -p datafusion-physical-expr test_in_list_dictionary_types --lib
• cargo clippy -p datafusion-physical-expr --all-targets --all-features -- -D warnings

Are there any user-facing changes?

No. This is an internal performance optimization only.

Benchmark note

No local in_list_strategy numbers are included for this PR because the benchmark harness does not currently include a direct UInt16 case. The available i16 rows measure the signed reinterpretation path added in #23013 after the bitmap unification in #23035, not this PR's unsigned UInt16 bitmap filter.