distill `rc-zip` down to fundamental types

[CosmicHorrorDev]

rc-zip contains the fundamental types for doing ~anything with the rc-zip-* crates, but it also contains a lot of additional complexity from the perspective of e.g. an rc-zip-{sync,tokio} consumer. i think it'd be much easier to keep the public API stable if all of the parser/fsm specific stuff was moved to some other crate (rc-zip-winnow maybe?) that can be kept as an internal implementation detail of rc-zip-{sync,tokio}

[fasterthanlime]

I would be interested in a more fleshed‑out proposal about this. rc-zip is a state‑machine based on purpose, so it would be strange, but I'm not entirely opposed to it. I just want to hear more about it—what types and functions would be in which crates, etc.

[CosmicHorrorDev]

coolio! i can open a draft pr of the idea at some point. the basic idea is making rc-zip a facade containing common types akin to http. roughly

• http -> rc-zip
• hyper -> rc-zip-winnow (*bikeshed name)
• axum/warp -> rc-zip-*

that way we can be a lot more aggressive with sem-ver breaking changes on rc-zip-winnow without breaking downstream crate's public APIs. given that winnow is still pre 1.0, so future breaking changes are expected. things could be wrapped to avoid exposing winnow types in the public api, but a slim core to build on would still be easier to keep stable