Optimize filter operations on integer arrays

As @alchemist51 reported in #237, liquid cache can be slower than baseline for the following query:

SELECT SUM(backend_status_code) FROM parquet_table WHERE backend_status_code=200

The data can be found at https://github.com/XiangpengHao/liquid-cache/issues/237#issuecomment-2940875412

This query has one filter column backend_status_code and the same column is used for final projection. This is not an ideal case for filter pushdown. Nevertheless, we can still optimize it.

The problem is here: https://github.com/XiangpengHao/liquid-cache/blob/9cefcf49b970a8208a930ed8daf9bb74ecb3a0b9/src/liquid_parquet/src/liquid_array/primitive_array.rs#L202-L208

When applying a filter to the liquid primitive array, we'll first decompress the entire array (line 203), then apply filter as arrow array (line 204-205), then compress the filtered array again.

This is not optimal, a better approach is to apply the filters directly on the encoded data. In liquid format, all primitives are eventually bit-packed -- they are fixed length bit chunks. It's not too difficult to apply filters on them.

Start in src/liquid_parquet/src/liquid_array/primitive_array.rs at lines 202-208, then review the linked benchmark data and issue #237. Trace how integer primitives are encoded and how filters are applied. Done means the filter can operate on the encoded data without decompressing and recompressing the entire array, improving the shown SUM query relative to baseline.