[feature]/rpc: update payment and invoicing related RPCs to include clear asset amt data

[Roasbeef]

Is your feature request related to a problem? Please describe.

Today when a user receives funds using an invoice created by tapchannelrpc.AddInvoice, the only way for them to be notified in the future that the invoice has been paid is via the existing SubscribeInvoices call. This RPC has been extended to include HTLC custom record data, so if a user knows the format, and how to parse that information, they can filter over that information. This puts a lot of burden on the end user, and having them re-implement protocol details is fragile, as the wire TLV records might change in the future.

On the flip side, when an invoice is paid using tapchannelrpc.SendPayment, show all the normal lnd information here, but the final amount sent is still in BTC. The RPC is streaming, and will return a accepted_sell_order field with some information. However that only includes the max payment amount (factoring in the fee limit) and not the final amount sent. Using ListPayments is also an option here, as we have the first_hop_custom_records field, but that once again assume the user knows how to parse that low level data.

Describe the solution you'd like

To resolve the first issue (knowing when you recv assets), we should make a wrapper around the existing SubscribeInvoices call for lnd. This call would handle filtering out non-asset invoice, and would also parse out the custom data information to easily present to users which asset they received, and the total amt for it. We may also want to add a ListAssetPayments call as well, which would implement a similar wrapper RPC pattern.

For the second issue, we should make a similar proxy call to parse out the information returned from lnd, locate and display the first hop custom records data, which includes the final amount we send outbound.

For both solutions, we should also consider adding new tables to tapd to store some of this information, to cut down the amount of RPC proxying we'd need to do.

Describe alternatives you've considered

Have the user parse out this data instead.