Add support for Equality Deletes on DeleteFileIndex

[rambleraptor]

Part of #3270

Rationale for this change

This adds support for getting equality deletes in the DeleteFileIndex.

I'm very purposefully ignoring them in _read_all_delete_files because they will crash.

Are these changes tested?

I made some equality deletes by-hand and had PyIceberg read them to see the indexes. Worked as expected. If you know a way to create equality deletes, I can test those as well.

Are there any user-facing changes?

• Adds support for equality deletes in DeleteFileIndex

[ndrluis]

@rambleraptor I think we should add a regression test for schema evolution here. This pruning path assumes the current table type for an equality field is the same type that was used when the data file and equality delete were written, which is not always true after a legal promotion like int -> long. In that case, historical manifests still contain 4-byte int bounds, and decoding them with the current LongType can fail in DeleteFileIndex.for_data_file(...).

For reference, Iceberg Java had to address the same schema-evolution issue in apache/iceberg#15268, where the fix was to avoid assuming the current schema is always the right one for equality-delete field resolution.

[rambleraptor]

Thanks @ndrluis for the suggestion. I opened #3293 to handle the type promotion case for the historical manifests. It looks like we're not handling that properly and I don't want to pollute this PR too much.

[rambleraptor]

@geruh @kevinjqliu @Fokko please take a look when you can!

[rambleraptor]

I've successfully tried this out with Flink (thanks @Fokko for the tip!) and it's working as I expect it to. Is it worth checking in the files created by Flink?

[geruh]

Nice, thanks for opening @rambleraptor!!! Left some comments below.

Also, +1 to add to the flink testing and I believe there were talks about this being added to the TCK! While working on #2255, we tested all delete file combinations with flink.

[rambleraptor]

@geruh thanks for the review!

Could not agree more on the Flink testing! I'll leave that for a follow-up PR if that's alright, since we haven't stood up Flink testing yet. I don't want to pollute this PR too much

[rambleraptor]

@geruh thanks so much for your review! ptal