Decouple breaking changes of omniqueue from breaking changes of redis, lapin

[svix-jplatte]

Currently, the rabbitmq and redis backends use types from the lapin and redis crates in the public API. This means upgrading one of these dependencies to a new semver-incompatible version changes our public API and it semver-incompatible for omniqueue. It's unfortunate if we have to make semver-incompatible releases when things only change for users of one specific backend. I see two solutions to this:

• Make these dependencies private: We would have to duplicate parts of the public API of those crates and convert from omniqueue types to the types of those crates internally. This gets more complicated the more configuration knobs we want to expose for queue initialization (e.g. Be able to use one connection for multiple producer/consumer #61)
• Split omniqueue into multiple crates: I.e. if you want to use omniqueue with the redis backend, you cargo add omniqueue omniqueue-redis and import paths change from omniqueue::backend::redis (or omniqueue::backend) to omniqueue_redis. This makes publishing slightly more complicated for when there are breaking changes in the base / core crate since multiple crates now have to be released, and some users might find it less convenient. However, it seems like it would be less work overall and would also help compile times.

I'm currently in favor of the second option.

Potentially worth noting: While the second option might seem to be a bigger change for users, I think it actually offers the better migration paths because we can deprecate the existing backends¹ and have new backend crates work with the older omniqueue release by using the semver trick of having it re-export traits from the newer release.

¹ likely behind a feature flag that we tell users to only enable before upgrading to the next semver-incompatible version, like clap does