Expiring queues should dead-letter messages when a dead-letter-exchange is defined

### Present Behavior
Even when a dead-letter-exchange is defined for a queue that has a TTL set (x-expires), when the queue expires, the messages are lost.

### Use Case
One approach to providing isolation guarantees in addition to horizontal scalability is to allow every service instance to have it's own queue. Unfortunately, if the connection is severed between the service instance and its queue, (or the instance crashes) messages are 'orphaned' in the queue with no elegant way to detect this issue and recover the messages. (per-message TTL is very problematic because its dependent upon average message process time and queue depth)

### Test Case
In a system that needs to provide some level of isolation guarantees (say by using a consistent hashing exchange using correlation id for hashing), each new service instance would define its own queue bound to the consistent hash exchange with a TTL and the consistent hash exchange as the dead-letter-exchange.

Messages were published to the consistent hash exchange and split amongst queues. One queue's consumer is terminated and after the TTL expires, the queue is removed and all messages are republished to the consistent hash exchange and effectively redistributed to the remaining queues.

### Request For Comments
Please let me know if this behavior would be undesirable, it fits our use case perfectly but if there's a different set of configurations we could use to get the same benefits, we'd like to know about those.

If there are problems with the code as its written, I'd be happy to make any changes necessary in order for this PR to be suitable for further consideration.

If my implementation is so problematic that it would be easier to just ignore and have a core committer add the feature properly, I totally understand. I tried it partly for the learning experience and partly out of a desire to potentially contribute to an excellent piece of software I've been using every day for a long time.

### Workflow
It looks like GitHub is not the normal avenue for submitting changes but I'm far less familiar with Hg and wasn't sure how to (or if I could) create a ticket in your system for a feature in order to match the branch to the ticket number. 


It says a lot about RabbitMQ's team and implementation that I could pull something like this off in a few hours of source diving. Sorry if I've made a big mess, as I mentioned, this would be a huge win for us going forward if we could get this behavior implemented.