Fix some issues with arrow expression eval

[scovich]

Three things:

1. The nested column extraction code was overly complex. Simplified.
2. The in-list extraction code was doing redundant nested column extraction. Clean it up.
3. One of the in-list unit tests was claiming to verify IN but actually executed NOT IN. Fix it.

[codecov]

Codecov Report

Attention: Patch coverage is 84.61538% with 4 lines in your changes missing coverage. Please review.

Project coverage is 78.25%. Comparing base (025aba8) to head (06be812).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
kernel/src/engine/arrow_expression.rs	84.61%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #401      +/-   ##
==========================================
- Coverage   78.34%   78.25%   -0.09%     
==========================================
  Files          49       49              
  Lines       10282    10256      -26     
  Branches    10282    10256      -26     
==========================================
- Hits         8055     8026      -29     
- Misses       1775     1780       +5     
+ Partials      452      450       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zachschuermann]

LGTM just a couple nits for comment/follow-up

[zachschuermann]

maybe a super quick example would also be useful? e.g. parent is complex struct column a and field names are [b, c] means we return a ref to the nested column c? am I understanding correctly?

[scovich]

Exactly. Added the missing doc comment.

[zachschuermann]

do we still need to have a follow-up in order to properly handle nested columns (instead of just naive split('.')?)

[scovich]

Definitely. My WIP nested column code already handles it.

[scovich]

Ah, you refer to the deleted TODO comment. Reinstating it.