Switch const serialize to use CBOR

[ealmloff]

Currently const serialize uses a bespoke endianness erased packed format which is very simple to support, but is not self describing. This makes any change to the layout of the data including adding fields or adding enum variants a breaking change.

This PR switches to CBOR which is both a relatively simple format to support and is self describing.

While this PR should make breaking changes to manganis more forgiving in the future, the change in format itself is breaking because old version of the CLI don't know how to deserialize the new cbor format

TODO:

• Numbers
• Arrays
• Structs
• Enums
• Bytes
• Strings *
• Documentation + final review

*: implemented CBOR encoding and decoding, but not used in const-serialize

Closes #4863

[jkelleyrtp]

I wonder if we might be able to add a header with a magic number to identify different versions from each other, letting us support the old format and the new cbor format both in 0.7

[ealmloff]

I wonder if we might be able to add a header with a magic number to identify different versions from each other, letting us support the old format and the new cbor format both in 0.7

Supporting the old version of assets in the new version of the CLI is fairly easy. The difficult case is supporting the new version of assets in the old version of the CLI.

If you run cargo update dioxus will be updated and the new version of assets will be used, but dx will not be updated and will fail to deserialize the new assets

[jkelleyrtp]

Supporting the old version of assets in the new version of the CLI is fairly easy. The difficult case is supporting the new version of assets in the old version of the CLI.

We could push an update that reads the current dx version in dioxus and then throws an error if dx is too old for the current dioxus. I think we might already throw an warning in the CLI, but we could make this release a hard error.