Use byte arrays to store non-unicode fate strings

[davidyuk]

extracted from #287

This PR is supported by the Æternity Foundation

unicode strings implementation - why and how

Firstly, if a contract uses fate strings as bytes, then these bytes can be broken by converting them to strings on js side. To avoid that I propose to keep data as bytes, keeping the same API except that valueOf will return bytes instead of a string if the payload is non-unicode.

The issue I had is that some arguments in contract instructions are raw strings, the current implementation breaks them while decoding making impossible to encode them back. For example:

  {
    id: '1f734048',
    name: 'test_bls12_381_fp',
    attributes: [],
    args: { name: 'tuple', valueTypes: [ { name: 'int' } ] },
    returnType: { name: 'bytes', size: 48n },
    instructions: [
      [
        {
          mnemonic: 'PUSH',
          args: [ { mod: 'arg', arg: 0n, type: { name: 'int' } } ]
        },
        {
          mnemonic: 'CALL_T',
          args: [
            {
              mod: 'immediate',
              arg: '��u�', // OR Uint8Array(4) [ 243, 237, 117, 150 ] after this PR
              type: { name: 'string' }
            }
          ]
        }
      ]
    ]
  },

[dincho]

The issue I had is that some arguments in contract instructions are raw strings,

Maybe we shouldn't decode such arguments as strings but byte arrays? I'll take a closer look.

The PR idea is common-sense at first, but the results are a bit controversial for me still. The Unicode check is also heart-breaking.

[dincho]

Not really happy, but it is what it is as FATE strings are really byte arrays. I don't have better ideas.