Don't use parquet file offset for file range pruning

[tustvold]

Which issue does this PR close?

Closes #5995

Rationale for this change

file_offset is not the offset into the file where the column is located, but rather is the location of non-inlined metadata - https://github.com/apache/parquet-format/blob/master/src/main/thrift/parquet.thrift#L781. Some writers such as DuckDB will set it to 0, causing all row groups to be scheduled into the same partition

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[alamb]

I will give this a test on my performance machine

[alamb]

I ran this on reproducer from #5995 and indeed it now goes much faster on the duckdb generated file.

Thank you @tustvold

+--------------+--------------+----------+-----------------+-------------------+---------------------+--------------------+--------------+----------+-------------+
| l_returnflag | l_linestatus | sum_qty  | sum_base_price  | sum_disc_price    | sum_charge          | avg_qty            | avg_price    | avg_disc | count_order |
+--------------+--------------+----------+-----------------+-------------------+---------------------+--------------------+--------------+----------+-------------+
| A            | F            | 37734107 | 56586554400.73  | 53758257134.8700  | 55909065222.827692  | 25.522005853257337 | 38273.129734 | 0.049985 | 1478493     |
| N            | F            | 991417   | 1487504710.38   | 1413082168.0541   | 1469649223.194375   | 25.516471920522985 | 38284.467760 | 0.050093 | 38854       |
| N            | O            | 74476040 | 111701729697.74 | 106118230307.6056 | 110367043872.497010 | 25.50222676958499  | 38249.117988 | 0.049996 | 2920374     |
| R            | F            | 37719753 | 56568041380.90  | 53741292684.6040  | 55889619119.831932  | 25.50579361269077  | 38250.854626 | 0.050009 | 1478870     |
+--------------+--------------+----------+-----------------+-------------------+---------------------+--------------------+--------------+----------+-------------+
4 rows in set. Query took 0.706 seconds.