Serialize/Deserialize unsorted maps separately from PlutusData

[MitchyCola]

CSL uses BTreeMap in it's default implementation for serializing/deserializing CBOR maps from/to PlutusMap. Lexicographically ordered keys are an invariant property of BTreeMap. This has an adverse effect on smart contracts that expect datums that contain unsorted maps, where the smart contract would need to sort the map in order to perform validation. This would waste onchain resources for unnecessary computation.

IndexMap preserves the order of insertion and, therefore, can be used to simulate the behavior of Plutus's associative map. Since the Ord trait cannot be derived for IndexMap, it could not be included in a constructor for PlutusDataEnum. The data type PlutusDatumMap was created so that an IndexMap can be serialized/deserialized independent of PlutusData.

After separate serialization of a PlutusDatumMap, the CBOR can be added into the PlutusData structure by using PlutusData::new_datum_map. And for deserialization, the CBOR for the map can taken by using PlutusData::as_original_bytes and can then be separately deserialized into PlutusDatumMap where an FFI program can unpack the items that are contained in the PlutusDatumMap.

[KristianBalaj]

LGTM. Except, I would undo the change to authors and copyright, etc.

[MitchyCola]

Right, I will fix that. I just quickly replaced all instances of the authors.

I will wait to merge this in until @codybutz creates an NPM account for Indigo that we can upload this to. Then I can also update downstream dependencies.