[feature]: smarter SendPayment that sends sats or assets, whatever is required.

[ZZiigguurraatt]

We need a smarter version of SendPayment that can send either sats or assets, whatever is required by the peer and invoice.

This issue addresses the opposite of what is discussed in #1421 (comment) .

                      TAP
 alice <-----> bob <------> charlie
         SAT    ^     SAT      ^
                |              |
                |S             |S
                |A             |A
                |T             |T
                |              |
                v              v
              goerge <-----> henry
                       SAT

Let's say Charlie wants to be paid only in taproot assets. He creates does an RFQ and negotiates an exchange rate with edge node Bob. After the quote is accepted, Charlie and Bob affiliate the quote/exchange rate with a SCID and the instead of forwarding the sats, the two agree that some assets will be delivered instead if attempted to be routed through that SCID. Then Charlie creates an invoice for the sats to assets exchange rate that was agreed upon and adds some route hints for that SCID. If a payment tries to be routed along that SCID, they both know that taproot assets should go down it.

Charlie then sends the invoice to Alice. Alice doesn't know what taproot assets are and just wants to pay the sats invoice. Alice creates an HTLC with Bob for the sats and Bob then creates an HTLC with Charlie for the agreed upon amount of assets. The preimage is released and all the payments settle. Bob gets sats and Charlie gets assets. Everyone is happy.

If Charlie instead gives this invoice to Bob and Bob tries to pay the the invoice in sats and the payment fails. This failure is tested for in

https://github.com/lightninglabs/lightning-terminal/blob/b65e703fa5e59e12fd2bff981a30bfff3df397a5/itest/litd_custom_channels_test.go#L512-L531

The reason it fails is because Charlie asked Bob if he would forward a payment for sats and give Charlie an asset and Bob agreed to. Bob however did not know that Charlie was going to give the invoice directly to him to pay. You could say this is not fair to Bob. However, Bob already agreed to an exchange rate for assets, so he can't change his mind and send sats instead. Bob had the opportunity to choose an exchange rate that is in his best interest over Charlie's, so he actually has no rational reason to change his mind and want to send sats instead. Therefor, we don't need to give a special exception to allow Bob to pay this invoice with sats even though the rest of the network could.

However, from a gRPC perspective, we need to have a more general SendPayment function that can figure out if the invoice that is being paid already committed to actually needs to pay in taproot asset or sats. Since a node can be used for many different applications, an application developer may not know that the node is taproot asset capable and/or they may not have a macaroon that gives them permissions to see that an RFQ was already negotiated for that SCID in the hop hints. The application may not know that the invoice was received directly from a peer. An application developer just wants a simple way to be able to receive any invoice and pay it (however the underlying node needs to pay it).

Also, bob can't route the payment through george and henry to pay in sats because the invoice was tied to the SCID that charlie established with bob (which is included in the invoice), so charlie shouldn't accept payments through that route.