Dynamic kernel procedure invocation

[bobbinth]

Currently, when making calls to kernel procedures we invoke them statically (i.e., via their MAST roots). This approach has a significant downside: any time kernel procedures are modified, any procedure invoking them would also have their MAST changed.

For example, receive_asset procedure from the BasicWallet interface relies on the account_vault_add_asset procedure in the kernel. If we were to modify anything about this procedure (i.e., make an optimization or fix a bug), MAST root of receive_asset would change rendering all P2ID and other notes which rely on receive_asset useless.

What we need is the ability to update the underlying kernel without changing procedures that rely on it. One way to do this is to make all kernel calls dynamic. Specifically, this could work as follows:

1. Instead of individual kernel procedures we'd have a single procedure - e.g., exec_kernel_proc.
2. This procedure would take an index of the actual procedure to call and a set of parameters to call the procedure with.
3. Internally, this procedure would look up the MAST root of the procedure to be called based on the specified index and use dynexec instruction to execute it.

To give a concrete example of how this would work for the receive_asset procedure:

1. receive_asset procedure would remain exactly as it is now - i.e., it would still call account::add_asset procedure.
2. account::add_asset procedure would now look something like this:

   export.add_asset
       # push the index of the account_vault_add_asset procedure onto the stack
       push.ACCOUNT_VAULT_ADD_ASSET_IDX
   
       # call the generic procedure executor
       syscall.exec_kernel_proc
   end
   

3. Inside exec_kernel_proc procedure we'd first look up the root of account_vault_add_asset procedure and then call it via dynexec.

For point 3 above to work, we need to have the map from procedure index to MAST root somewhere in the kernel memory. This map can be built during transaction prologue. Basically, transaction prologue would take hash of the transaction kernel as an input and "unhash" it unto some well known location in memory. Then, the lookup would be as simple as adding the relevant offset to the provided procedure index and reading MAST root from the resulting memory address.

One open question is how kernel hash should be provided to the prologue. A couple of options:

1. It could be provided as an independent transaction input (i.e., via the stack).
2. It could be implied by the block reference used when executing a procedure.

[bobbinth]

Closed by #803.