Move `AckStream`, `DropStream` and `ResponseHandlers` into core behind the remote-adapter feature flag

[Totodore]

Move these stream constructs to core and make it generic so they can be used by each adapters.

[Totodore]

@LiamCarPer let's implement this first in a PR and check the other items later.

[LiamCarPer]

Sounds good, I'll open a draft PR once I have the core module ready so you can check the approach.

[LiamCarPer]

I have a few questions before i start on this:

1. AckPayload (Postgres-only), it has JSON/MsgPack duality and is specific to how postgres handles attachments. Should it stay in the postgres crate, with just the RemoteAckPayload trait impl there, or move to core too?
2. ChanStream / MessageStream, both the postgres and redis crates have a generic mpsc::Receiver wrapper that implements Stream (postgres calls it ChanStream, redis calls it MessageStream). MongoDB's is hardcoded to Item. I can consolidate to a single ChanStream in core. OK?
3. Unit tests, the local_ack_stream_should_have_a_closed_remote test is duplicated in all 3 adapters. I'll move one copy to core. Any adapter-specific tests I should add?
4. DropStream<S, T>, the second generic T is the mpsc sender value type (phantom DropStream only calls .remove() on the map, never touches the value). Does that make sense or would you prefer a different approach?

[Totodore]

1. For AckPayload, it should remain in the postgres adapter. We should only refactor shareable constructs.
2. Yes, let's move ChanStream in core.
3. I cannot say at the moment.
4. Good for DropStream<S, T>.