If the target queue died normally we don't care, and if it died
abnormally the reason is logged by the queue supervisor. In both cases
we treat the message as unrouted.

When we fire off lots of gen_server:calls in parallel, we may create
enough work for the VM to cause the calls to time out - since the
amount of work that can actually be done in parallel is finite.

The fix is to adjust the timeout based on the total workload.

Alternatively we could not have any timeout at all, but
that is bad Erlang style since a small error somewhere could result in
stuck processes.

I moved the parallelisation - and hence timeout modulation - from the
channel into the amqqueue module, changing the API in the process -
commit, rollback and notify_down now all operate on lists of
QPids (and I've renamed the functions to make that clear). The
alternative would have been to add Timeout params to these
three functions, but I reckon the API is cleaner this way,
particularly considering that rollback doesn't actually do a call - it
does a cast and hence doesn't require a timeout - so in the
alternative API we'd either have to expose that fact indirectly by not
having a Timeout param, or have a bogus Timeout param, neither of
which is particularly appealing.

I considered making the functions take sets instead of lists,  since
that's what the channel code produces, plus sets have a more efficient
length operation. However, API-wise I reckon lists are nicer, plus it
means I can give a more precise type to dialyzer - sets would be
opaque and non-polymorphic.