grc721: Remove redundant on-chain Metadata struct

[stefann-01]

Description

Despite our Metadata struct being modeled after OpenSea's metadata standards (as referenced in the comment in igrc721_metadata.gno), our implementation actually makes OpenSea integration more difficult.

Problem:

1. OpenSea expects metadata to be served via TokenURI() as a JSON endpoint
2. Our on-chain Metadata struct duplicates the JSON format, but OpenSea cannot read it - they only fetch JSON from the URL returned by tokenURI
3. Having both TokenURI and on-chain Metadata is redundant and potentially confusing for users
4. Storing this data on-chain is:
   • Wasteful of chain storage
   • More expensive (gas costs)
   • Inflexible for updates
   • Unable to handle large media files that OpenSea supports

Solution:

• Remove the Metadata struct and related methods
• Keep only TokenURI functionality as the standard way to reference metadata

This will make our NFTs actually compatible with OpenSea while following blockchain storage best practices.

Update:

After further consideration, I realized that there is one potential use case where the on-chain Metadata struct could be useful: rendering NFT images in the Render function for Gnoweb.

Since it is not possible to resolve a URI response inside the chain (in realms), and there is no mechanism in Gnoweb to handle the TokenURI JSON response, there is currently no way to display the image of an NFT within Gnoweb.

By using on-chain metadata, which includes a direct image URL, we can leverage this URL in the Render function, enabling .md in Gnoweb to render the image.

This highlights a scenario where storing Metadata on-chain allows direct rendering of NFT images in the Gnoweb, but I believe a better way of enabling this feature would be to add this capability directly into Gnoweb, instead of unnecessarily complicating the grc721 implementation.

[thehowl]

cc @leohhhn for feedback

[moul]

Let's remove metadata from both GRC721 and GRC20 to simplify the process. We can use an interface if necessary.

Let's completely refactor GRC721 as we did for GRC20. It would also be helpful to create a meta issue for this. Please check my recent #3510.