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. ManifestReader's stats-based pruning 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 and leave
a row that should have been deleted in the query result.

Only skip metrics evaluation for an equality delete file when the row
filter references a column outside its equality_ids; pruning using the
equality-key columns' own stats remains sound and is preserved.

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. 🙏