Support clients that don't handle returned messages

[victorges]

Following up on #29

There is a possible issue with the publisher logic due to the fact that it always creates
a NotifyReturn channel around here, but doesn't really know or even have a way to
enforce consumers of the library to actually consume that channel.

By not controlling whether the channel will be really consumed in the end, it is possible
that that background go-routine would get stuck in the exact line referenced above. This
means not only a go-routine possibly leaking in the background, but actually the whole
*amqp.Channel loop hanging as well, since they also have no protection against channels
with no consumers on the other side, as you can see here.

What they do have protection on is that they won't send to a channel that hasn't been
explicitly subscribed with a Notify* function call, so the implicit contract there is that
if you subscribe to a channel, you should read all data sent to it or it should have enough
buffer not to hang the senders (which for cancel/closed channels it can easily be 1 #29).

My suggestion is to do something similar and not create a return channel automatically,
but actually only if the consumer calls some function like Returns() chan Return, setting
up the return channel lazily and only after consumer expressing intent of actually
processing it. That would require some interface changes though like not returning a return
channel from NewPublisher or creating an alternate constructor and updating docs on
the current one to clarify that consumers must listen to the channel if they use mandatory
or immediate publishings.