Fix #62 incorrect hex of the locking script

[zhfnjust]

The locking script of the sCrypt contract is somewhat special. After the last opreturn, there may be situations where the data is not stored according to oppushdata. But this is subject to agreement.

For example, under normal circumstances:

4c03000000 // OP_PUSHDATA1, len = 3, data = 000000

But the scrypt contract will have the following situations:

4c0300 // OP_PUSHDATA1, len = 3, data = 00

data only has one byte.

We have to deal with this situation. Otherwise, the correct signature cannot be obtained.

[zhfnjust]

@deanmlittle can you merge this , and republish it.

[zhfnjust]

@deanmlittle The current implementation of the interpreter is incomplete and I cannot add tests for rawdata

[zhfnjust]

[zhfnjust]

Hi, @deanmlittle , I think we can check NonScriptData in the following three situations:

1. Dynamic, that is, in the script virtual machine, when push NonScriptData always be error here

2. Static, when deserializing hex. The algorithm itself has ensured that NonScriptData only appears after OP_RETURN and at the end. here

3. Static, when new a Script from a passed ScriptBits, we ensured the passed ScriptBits only contains NonScriptData at toplevel and after OP_RETURN here

Since previous ASM could not correctly represent cases containing malformed NonScriptData, such as: "6a4c0300", the following ASM format is now used:

OP_RETURN non-script-data:4c0300