[feature]: Implement "Asset TLV Placeholder" Design for Decimal Display

[dstadulis]

Context

Given the scope of https://github.com/lightninglabs/taproot-assets/issues/956 is board, @roasbeef proposed an alternative strategy to achieve, eventual, protocol-level enforcement of an asset decimal display TLV

Description

As proposed by Roasbeef, this issue aims to specify an unserialized asset TLV (Type-Length-Value) placeholder that will reserve space for decimal display without fully delivering the feature. This design will ensure that the TLV is bound to the asset while allowing for future development and interpretation of the stored opaque blob.

Requirements

Tasks to complete

• [ ] Bump version: Increment the version number to reflect the changes.
• [ ] Opaque blob storage: Store an opaque blob in the asset, which will be interpreted later.
• [ ] Old client compatibility: Ensure that old clients can recognize and serialize the asset using normal asset serialization methods, even if they don't understand the new TLV placeholder.

Inspiration

This implementation should draw inspiration from how Lnd wiremessage reads past the point of concrete values.

Deliverables

• [ ] Unserialized asset TLV placeholder that reserves space for decimal display
• [ ] Version number increment
• [ ] Opaque blob storage and later interpretation mechanism
• [ ] Compatibility with old clients

Describe alternatives you've considered If decimal display is solely specified via JSON then there will likely be on going tech debt necessary to support it and alternative taproot asset implementations could fault. While decimal display isn't protocol state machine consensus critical, it does have a drastic effect on the human interpreted values.