Define JSON format constraints for interfaces

[austinabell]

Currently, with the Rust SDK (and standards implementation by extension), we allow deserializing parameters as a map with named keys OR as an array of ordered values through serde/serde-json.

For example, take the nft spec interface:

function nft_transfer(
  receiver_id: string,
  token_id: string,
  approval_id: number|null,
  memo: string|null,
) {}

The parameters for calling this function will either be:

{"receiver_id":"a.near","token_id":"1","approval_id":2,"memo":"hello"}

OR

["a.near","1",2,"hello"]

The ambiguity of deserialization isn't an issue since the parameters aren't canonical anyway since we are stuck with JSON (unless we start asserting ordering of named parameters of maps and disallow whitespace). The latter option is much more concise, reducing costs and quicker debugging, but we need to be clear if and how this is allowed in specs.

The options for deserialization seem to be:

1. Only specify that named parameters are required to be supported, disallow any other format
2. ..., allow any other format up to the implementation to support (seems this is currently the case)
   • Document the optional sequence format
3. Require implementations to accept either format for parameters

cc @jlogelin