feat: transactions within one block from a single account should be executed in nonce order

[ppedziwiatr]

There should be an option for the user to decide what is the order of execution of his interactions mined within one block. Currently - if two or more transactions for given smart contract are mined within one block, the order of execution depends on the ordering of sha256(transactionId + blockHash) - because of the random nature of the transactionId, it cannot be guaranteed that the order of execution will be the same as the order in which the transactions were posted.

An example use case would be:

1. User creates an interaction that approves token transfer on token contract
2. User creates an interaction that stakes tokens on staking contract (which underneath calls the token's contract "transferFrom" - firstly verifying if there's enough allowance (so the transaction from point 1. should be executed as first))

Original issue: https://github.com/redstone-finance/redstone-smartcontracts/issues/47

[ppedziwiatr]

Assumptions:

1. setting nonce is optional. If on a given block there are transactions from one wallet address with and without nonce set - the ones with nonce take precedence.
2. nonce is an optional parameter to the interactWrite function (using the original smartweave.js functions naming), only integer values ranging from 1 are allowed.
3. The nonce affect the ordering only within the transactions on a one given block (not globally).

Protocol changes:

1. Setting the nonce parameter in the interactWrite should result in creating a new tag in the interaction transaction - Nonce
2. Sorting: The sorting algorithm first sorts the interactions according to the current specs. Each generated sortKey should have a wallet address assigned (Transaction.owner). Next - for transactions within given block, based on the value of the Nonce transaction tag, we rearrange the order - but only within the "slots" associated with a given wallet address.

Example: Let's say that original ordering of transactions (i.e. generated by the current sorting alg) for contract x at block height y looks like this:

1. owner1 tx1 nonce 3
2. owner2 tx2
3. owner1 tx3 nonce 2
4. owner3 tx4
5. owner2 tx5 nonce 1
6. owner1 tx6 nonce 1

After applying the nonce-based sorting, the final ordering of transactions for contract x at block height y would be:

1. owner1 tx6 nonce 1
2. owner2 tx5 nonce 1
3. owner1 tx3 nonce 2
4. owner3 tx4
5. owner2 tx2
6. owner1 tx1 nonce 3