Extract DeletionVector logic from PuffinFile

[ebyhr]

Rationale for this change

PuffinFile handles two tasks: format parsing (magic bytes, footer, blobs) and deletion vector domain logic (bitmap deserialization and PyArrow conversion).
This will become problematic when we introduce support for the NDV apache-datasketches-theta-v1 blob in the future.

Are these changes tested?

Yes

Are there any user-facing changes?

Yes - PuffinFile class user needs to call DeletionVector.

[sungwy]

Thanks for working on this PR @ebyhr and I agree this is a good cleanup.

I added some comments

[ebyhr]

Thanks for your review! Addressed comments.

[sungwy]

Thanks for this contribution @ebyhr . I've approved it, and I'll leave it open for a day for any additional reviews before we merge.

[moomindani]

Thanks for splitting this out — the read path looks behavior-preserving and the separation is clean.

For the write side, we'd like to coordinate before building on top of this: once it lands we're planning to rebase #3474 (the DV writer, currently PuffinWriter → to be renamed DeletionVectorWriter) on top of it, moving the writer along with its _serialize_bitmaps helper and the DV-specific constants into deletion_vector.py and reusing MAX_JAVA_SIGNED / PROPERTY_REFERENCED_DATA_FILE from here.

Given that, would it make sense to decide now whether the write/serialize path should live on DeletionVector itself (mirroring from_puffin_file / to_vector with a serialize counterpart) or as a separate DeletionVectorWriter class?

Our preference would be to mirror the read-side split — keep the DV bitmap serialization on DeletionVector (as the counterpart to from_puffin_file / to_vector) and leave the generic Puffin-file assembly as a format-level writer in puffin.py, so the write path scales to the future NDV blob the same way the read path now does. That said, we're happy either way.