🔭 Conform Guardian generated NFTs with HIP412 for better ecosystem-wide compatibility for NFTs and wallets

## Problem description

Currently, Guardian-generated NFTs use a proprietary metadata Guardian, this is fine, if we want to align ourselves with the members of the NFT and wallet ecosystem we should integrate [HIP412](https://hips.hedera.com/hip/hip-412).

> Note: this specifically effects guardian NFTs, rather then FTs.

@mattsmithies can help advise Guardian team on getting assets HIP412 compliant.

### Why this matters

In a sentence, the UX that downstream consumers that purchase carbon assets must be good.

When we expect carbon or similar environmental assets (biodiversity) to be generated and transferred to the wallets of network users on Hedera there will be an expectation of these assets being sold on external markets at a later time. This specific usecase is on assets that aren't retired at point of sale on given marketplace.

Currently, DOVU provides a marketplace that retires carbon for every sale but we will be moving to decoupling the carbon retirement process, as well as moving to a retirement architecture that includes lifelong analytics.

The issue is when NFT assets generated from the Guardian are transferred to a wallet the lack of [HIP412](https://hips.hedera.com/hip/hip-412) integration means that end users have bad experience when viewing.

#### Examples:

This screen displays the collection of NFTs, in this case tons of carbon transferred to a wallet where each tonne is one NFT.


This next screen displays a single NFT, from the collection that is a tonne of carbon.


This [next link is of gomint's NFT explorer](https://gomint.me/explore/NFT/?tokenId=0.0.49253572-1&network=testnet), which renders from the HIP412 schema.

## Requirements

1. Define senisble defaults for all NFT Guardian assets that is the minimum implementation of HIP412 (@mattsmithies can advise on tooling or a method to support)
2. Move the generated of the current metadata to the *"properties"* field of the [HIP412 Specification](https://hips.hedera.com/hip/hip-412#specification)
3. Allow marketplaces to change the defaults for their specific needs on the creation of tokens and more importantly the mint of assets.

## Definition of done 🔥

**All** guardian NFT assets should conform to HIP412, to enable wallets and external services to injest the information to render.

An example of a valid NFT is this [Carbon Certificate DOVU issued to Swirlds](https://gomint.me/explore/NFT/?tokenId=0.0.1687320-1&network=mainnet) for the Davos event, we can pull from a mirrornode to extract the data to infer and write automated tests against.

### Acceptance criteria

- A standard registry can transfer NFT assets and view them in Hashpack (HIP412 compliant wallet) with a placeholder image
- A standard registry can set the following fields for the mint of a guardian NFT asset
- Name
- Creator (standard registry)
- Description
- CID (from the upload of an image from nft.storage, web3.storage or others)
- Type (image/png or video/mp4)
- A user that gets NFT carbon assets transferred to an account, will either see sensible defaults or the
- As a developer using the guardian I can run an automated test that can check that a minted NFT conforms to HIP412.

## Appendix

For DOVU we built/utilised the [Trust Enterprises NFT ecosystem](https://docs.trust.enterprises/rest-api/nft-ecosystem) using the Inky Art Club admin panel as a frontend minter for the Swirlds Certificate for Davos.