Message delivery stops if register_callback is not called

Hi, I ran into an issue while using `amqprs` because I didn’t explicitly call `register_callback` on a `Channel`. After some time, I encountered the following error: https://github.com/gftea/amqprs/blob/b14adfcff413f3b593875a32522a8a5f76a5ad3b/amqprs/src/api/channel/dispatcher.rs#L541 then the server just stops delivering messages to the consumer. What surprised me is that registering the callback is documented as something you *should* do, but in practice it behaves like something you *must* do. If you forget it, everything compiles fine, the channel is created, the consumer is started, and then after a while delivery just stops. Before proposing any fix, I’d like to better understand the rationale behind the current implementation. That said, the current behavior feels a bit dangerous from an API design perspective. It’s very easy to misconfigure the channel, and the failure happens at runtime for something that could potentially be prevented at compile time. Ideally, the API should try to prevent this kind of misconfiguration as much as possible. For example: * Maybe `DefaultChannelCallback` should be the default and `callback` should not be optional. * Or `callback` could be required as part of the channel construction, leveraging Rust’s type system so users are clearly aware that they must provide one. * Or the absence of `callback` should not break message delivery at all. It should be fully optional and not result in an error, with the internal logic working safely without it. In general, I feel like the library could lean more toward design choices that make incorrect usage impossible, especially when the alternative is a runtime error that silently stops consumers, expecially when `traces` feature flag is disabled. Thanks for the great work on the library