tapdb - [feature]: add new associative table to track asset burns ListBurns

[Roasbeef]

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

Today we have an easy way to burn assets, but no easy way to track all burns we've made for a given asset.

Describe the solution you'd like

With the way things work today, burns are just another transfer:

taproot-assets/rpcserver.go

Lines 3258 to 3282 in 420f246

	fundResp, err := r.cfg.AssetWallet.FundBurn(
	ctx, &tapsend.FundingDescriptor{
	AssetSpecifier: assetSpecifier,
	Amount: in.AmountToBurn,
	},
	)
	if err != nil {
	return nil, fmt.Errorf("error funding burn: %w", err)
	}
	// Now we can sign the packet and send it to the chain.
	_, err = r.cfg.AssetWallet.SignVirtualPacket(fundResp.VPacket)
	if err != nil {
	return nil, fmt.Errorf("error signing packet: %w", err)
	}
	resp, err := r.cfg.ChainPorter.RequestShipment(
	tapfreighter.NewPreSignedParcel(
	[]*tappsbt.VPacket{fundResp.VPacket},
	fundResp.InputCommitments,
	),
	)
	if err != nil {
	return nil, err
	}

However, we don't have an easy/efficient way to scan the transfers table for all the burns we've done:

taproot-assets/tapdb/sqlc/migrations/000005_transfers.up.sql

Lines 1 to 9 in 420f246

	CREATE TABLE IF NOT EXISTS asset_transfers (
	id INTEGER PRIMARY KEY,
	height_hint INTEGER NOT NULL,
	anchor_txn_id BIGINT NOT NULL REFERENCES chain_txns(txn_id),
	transfer_time_unix TIMESTAMP NOT NULL
	);

We should add a new associative table (that can store other meta data) that we add to each time we burn an asset. We should then create a set of queries to easily look up the set of burnt assets all time, for a given asset, etc, etc.

A draft table would look something like:

CREATE TABLE IF NOT EXISTS asset_burn_transfers (
     burn_id INTEGER PRIMARY KEY, 

     transfer_id BIGINT NOT NULL REFERENCES asset_transfers(id),
     
     note TEXT,

     asset_id BIGINT NOT NULL REFERENCES assets(asset_id),

     group_key_id BIGINT NOT NULL REFERENCES asset_groups(group_id) 
)

The note field can be used to store other metadata related to a burn.

Describe alternatives you've considered

A user can scan all the proof files on disk, to find those that end in a bug suffix, but this doesn't lend well to the creation of an automated system.