Hey! Thanks for this PR.

I've been looking into this, and while I initially thought this was bringing in a new dependency, I realized that ouch actually already pulls in ppmd-rust via sevenz-rust2. So from a strict dependency-weight perspective, this PR is essentially "free."

That being said, I have some reservations about merging this, mostly regarding the precedent it sets and the overall goals of the project.
I'd love to get @marcospb19's thoughts on this, as this touches on some core architectural decisions.

Here is what I'm thinking:

1. Inconsistency with existing features: Right now, ouch explicitly disables the default features on the zip crate (default-features = false). Because of this, we currently fail to extract bzip2 or zstd compressed ZIP files, even though we already have those dependencies in our tree for other archive formats. It feels strange to enable support for a highly obscure algorithm like PPMd for ZIPs while failing on much more common ones like bzip2 or zstd.
2. Standardization: PPMd inside ZIP files is incredibly rare. In fact, the ISO standard for document containers (ISO/IEC 21320-1) explicitly restricts conforming ZIP files to use only "Store" (no compression) or "Deflate".
3. Precedent: If we enable ppmd for the zip crate because the dependency is already there, it sets a precedent that we should probably enable all the other algorithms (bzip2, zstd, lzma) as well. While that might sound good, it goes against the explicit default-features = false decision and increases the surface area for bugs and maintenance.

@marcospb19 - What are your thoughts on this? Should we keep the zip crate features strictly minimized as they are now, or are you open to expanding the supported ZIP algorithms since the underlying dependencies are already present in our tree?