QoS Parameter for notification listeners

From Gordon in https://review.openstack.org/59713

Obviously durable (and/or replicated), reliable delivery is a little more computationally expensive (and potentially operationally complex, since there may be a need to deal with backlogs building in queues etc). If it is not needed/wanted in all cases, (and I suspect it is not), t would be nice to have some way to indicate which subscriptions had this particular QoS requirement. I guess that is what the autodelete/durable configuration options are for. I would think it would be better to have a uniform way of requesting a given QoS when creating the transport, and have it fail at that point if that QoS is not available. Throwing not implemented when you hit a problem is a little too late.