[feature]: multi RFQ send: shard weighted average `taproot-assets.experimental.rfq.acceptpricedeviationppm`

With https://github.com/lightninglabs/taproot-assets/pull/1613 we have the ability to split a payment across multiple shards to have a higher probability of payment success.

We don't have much control over the rate limits used used. Currently we only have taproot-assets.experimental.rfq.acceptpricedeviationppm to control if a rate is too high. This is a bit unflexible because we may only need a small shard to be sent through a high rate peer and the weighted average rate for all shards of the entire combined payment could be well under taproot-assets.experimental.rfq.acceptpricedeviationppm if most other outbound capacity is much lower than taproot-assets.experimental.rfq.acceptpricedeviationppm.

Would like to see some way to limit taproot-assets.experimental.rfq.acceptpricedeviationppm more intelligently based on the shard size actually used to send the payment.

Start by reading PR 1613 to understand multi-shard payment sending, then locate the handling of taproot-assets.experimental.rfq.acceptpricedeviationppm. Define how the rate limit should account for the shard sizes and weighted average across the combined payment; done means the behavior is specified and covered for multi-RFQ sends.