Map struct encoding

[rjharmon]

STILL a WIP (see add'l comment below). Merge after #127, which comes after #128.

Helios up until v0.17.0.93 allowed definition of a string-mapped struct (aka mStruct) in this form

struct MyStructDef {
  name: String
  description: String
  otherField: Int
}

This was encoded as a ConstrData(0, MapData), and it worked fine when a script's Datum was itself defined as an mStruct such as this myStructDef, and not an enum with a variant having field1: mStruct. Using that definition inside an enum variant would produce a second layer of ConstrData.

This change establishes:

• Datum enum variants with field1 as an mStruct will match the CIP-68 requirements (the Enum's ConstrData element provides that aspect of the requirement)
• Use of an mStruct in any position does no longer have a ConstrData wrapper, because it would be redundant

This represents a behavioral change versus version 0.16 (which expects a ConstrData in all cases when decoding an mStruct). Developers using such a struct as their Datum can continue getting CIP-68-compliant encoding by changing to an enum:

enum Datum {
  ForCip68 {
    data: MyStructDef
    version: String
    extraData: <any type>
}

[rjharmon]

As mentioned, this is still a work in progress; I had difficulty identifying the right changes to make in the IR for the mStruct to pass the on-chain is_valid_data check, given removal of the ConstrData wrapper.

It could use a couple more tests as well.

[rjharmon]

Some notes to clarify things for you (and reminders to me)

[christianschmitz]

Closing this particular PR because this work has been merged as part of #130 instead

[rjharmon]

just as hoped, thanks!