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.
• 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. Signed 1-byte and 2-byte types reuse these bitmaps in the next PR.

What changes are included in this PR?

• Generalizes the bitmap filter so different integer widths can provide their own storage and indexing behavior.
• Adds UInt16BitmapConfig, backed by a heap-allocated 65,536-bit bitmap.
• Routes UInt16 constant-list filtering to the bitmap path.
• Keeps the same IN / NOT IN null behavior as the generic path.
• Adds focused coverage for UInt16 boundary values, sliced arrays, nulls, and NOT IN.

Are these changes tested?

Yes.

• cargo fmt --all --check
• cargo test -p datafusion-physical-expr bitmap_filter_u16 --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, not this PR's unsigned UInt16 bitmap filter.