[bug]: `AddInvoiceResponse` only returns a single `accepted_buy_quote`

[ZZiigguurraatt]

AddInvoiceResponse only returns a single accepted_buy_quote. Now that we have #1457 , this does not make sense. I'm not sure if this is the worst accepted_buy_quote, the best, or the first one. We should have all accepted_buy_quote returned, and there should be an indication which one is used to set the sats amount in the invoice that is generated.

taproot-assets/taprpc/tapchannelrpc/tapchannel.proto

Lines 214 to 218 in e323b9e

	message AddInvoiceResponse {
	// The quote for the purchase of assets that was accepted by the peer.
	rfqrpc.PeerAcceptedBuyQuote accepted_buy_quote = 1;

I can decode the returned invoice to get a list of SCID and peer pubkeys used for each quote, but that does not tell me the quote amount, only which peers I also got quotes with. Also, I don't think a user should need to decode the returned invoice just to get the SCID and peer pubkeys.

[ZZiigguurraatt]

We've introduced the same problem for SendPayment in #1613 with accepted_sell_order:

taproot-assets/taprpc/tapchannelrpc/tapchannel.proto

Lines 160 to 165 in aa55b42

	// In case channel assets need to be swapped to another asset, an asset
	// sell order is negotiated with the channel peer. The result will be
	// the first message in the response stream. If no swap is needed, the
	// payment results will be streamed directly.
	rfqrpc.PeerAcceptedSellQuote accepted_sell_order = 1;

[ZZiigguurraatt]

We've introduced the same problem for SendPayment in #1613 with accepted_sell_order:

taproot-assets/taprpc/tapchannelrpc/tapchannel.proto

Lines 160 to 165 in aa55b42
// In case channel assets need to be swapped to another asset, an asset
// sell order is negotiated with the channel peer. The result will be
// the first message in the response stream. If no swap is needed, the
// payment results will be streamed directly.
rfqrpc.PeerAcceptedSellQuote accepted_sell_order = 1;

Actually, SendPayment streams a separate response for each PeerAcceptedSellQuote. This seems like it may be more backwards compatible of an approach and will allow things to be done more async, especially if a peer is unresponsive. Maybe this is also how AddInvoice should work?