Unspecialize wasm trigger registrations in genesis.json

[s8sato]

It seems to introduce inconsistency to me - why should triggers registration be different from other instructions? What if I need to intermix them in a custom order? etc.

I guess the answer is that it's hard to achieve due to the data model limitations - since we deserialise them as InstructionBox, we need to somehow patch the internals to load trigger from path. I think it is a bad path.

However, it's not the only way. It's possible to read genesis.json as a raw JsonValue and pre-process it before parsing into a data-model type. I.e. traverse instructions field, find Register/Trigger, find executable_path field there, load WASM, put it as a WASM blob into in-memory JSON value, then deserialise as a valid InstructionBox.

(same could be done for executor btw - load, put as a plain Upgrade instruction)

This might be an overkill for this PR, however. But from the standpoint of UX and API consistency this seems to be a good thing to do.

Originally posted by @0x009922 in #5027 (comment)

[s8sato]

To achieve genesis.json readability while keeping the instructions order flexible, my first suggestion in #5027 was to modify de/serialization of WasmSmartContract itself:

• on SerializeDisplay write a blob and display a hash
• on DeserializeFromStr find the blob by the hash and load it

Related to:

• Dedup wasm blobs #5185 suggestion 2.