Core: Don't prune equality delete manifest entries by non-key column stats

[findinpath]

An equality delete's match condition depends only on its equality_ids
columns. Per spec, the file may legitimately carry additional columns of
the deleted row, but their stats describe values that play no part in
the match condition. InclusiveMetricsEvaluator and StrictMetricsEvaluator
evaluated the scan's row filter against all of a delete file's column
stats, so a predicate on a non-key column could incorrectly prune a
delete manifest entry (inclusive) or cause it to be dropped from the
manifest entirely (strict), leaving a row that should have been deleted
in the query result. V4ManifestReader's stats-based filtering has the
same issue for v4 manifests.

Narrow stats to a file's equality_ids columns before metrics evaluation
for equality delete files.

Additional context

https://iceberg.apache.org/spec/#equality-delete-files

Equality delete files identify deleted rows in a collection of data files by one or more column values, and may optionally contain additional columns of the deleted row.

Is there a specific writer that does this (spark? flink? something else?)

Oracle GoldenGate

Issue found through trinodb/trino trinodb/trino#31399

[pvary]

I'm not entirely sure how much effort do we want to put into fixing this, as there is no current use-case for this. Especially considering that we would like to get rid of the equality deletes in the long run.
If we fix this then we should think about fixing this on the commit path as well (newDelete().deleteFromRowFilter), and this is where I'm really getting unconvinced.

[findinpath]

I'm not entirely sure how much effort do we want to put into fixing this

@pvary This represents a silent correctness issue.
We definitely should want to put effort into fixing such issues. 🙏

[pvary]

The more I think about this, we should read stats for non-eq columns.
Maybe even a spec change/clarification is warranted.