[feature]: Extend reporting of transitory/limbo transaction states (CLI/RPC)

[dstadulis]

When assets move into a transitory state (e.g. burning an asset), the daemon stops listing assets because it intends to remove them from the wallet's ownership. There's then an apparent UX disparity between 1) what's being reported by tapd 2) the state that's included in blocks 3) The state that could confirm by a broadcasted transaction. The daemon would benefit in terms of UX, and future functionality, by reporting these classes of transitory / limbo state. The CLI should be intuitive to users in the scenario where the burn etc is in limbo while the daemon waits for the transaction to be included in a block.

• User feedback has been given that transitory state not being available makes it confusing what's has or is about to happen
• Important to payment-channel functionality, the daemon's architecture will benefit from being able to keep track of and report pending transaction

Deliverable

tapd should be enhanced to report transitory / in-flight / limbo transactions lnd's lncli pendingchannels command could be a parallel:

https://github.com/lightningnetwork/lnd/blob/e6fbaafda4a9cfe08ccee5106aa6dc1da62bcebc/rpcserver.go#L3823-L3858

[dstadulis]

this functionality might be already available

[dstadulis]

In the state machine for transfer there is some record keeping of the state of proofs, could be a starting point @jharveyb will follow up with more code references

[jharveyb]

As an example for the transfer state machine (tapfreighter), we write info about the transfer before anchor TX broadcast:

https://github.com/lightninglabs/taproot-assets/blob/12d24398b8027b592fbf51d0ed17f4f21a3d30c0/tapfreighter/chain_porter.go#L1015

Which is later updated after receiver proofs are delivered:

https://github.com/lightninglabs/taproot-assets/blob/12d24398b8027b592fbf51d0ed17f4f21a3d30c0/tapfreighter/chain_porter.go#L744

It looks like we already expose these pending transfers:

https://github.com/lightninglabs/taproot-assets/blob/12d24398b8027b592fbf51d0ed17f4f21a3d30c0/rpcserver.go#L959

So we could maybe address this with doc updates, or decide to show those pending transfers outside of this ListTransfers call.