Cleanup & discuss consequences of VM API

[aionick]

The Avm took on the API defined in the VM API project starting at commit 76fd88b53135a1e09ef1da18b1f479ff48efa928. This API is still not in its final shape and some of it has been forced somewhat awkwardly upon the Avm.

I want to use this issue to track two things:

• Any changes to the Avm whose goal is to re-factor something into a more appropriate shape, to clean up after the API introduction.
• Any aspects of the API that seem unrelated to a VM, or that could benefit from a re-working, since a lot of these ideas are easier to glimpse from the Avm perspective on the matter.

Proposed changes to the Avm:

• [x] Implement getEnergyRemaining() in AvmTransactionResult.
• [x] Implement destinationAddressIsSafeForThisVM from KernelInterface to block fvm/precompiled calls.
• [x] Transaction constructor should take nonce as a BigInteger not a long, especially now that the KernelInterface returns a BigInteger.
• [x] Start using the SideEffects class properly and remove the data that will be tracked here from the AvmTransactionResult, where it no longer belongs.

[aionick]

Some API concerns:

• A VirtualMachine should probably take a transaction & KernelInterface as its input instead of a context. The KernelInterface really can account for the context, and it feels awkward to have to enclose a transaction inside of its so-called context so that the VM can use it.
• InternalTransaction has a lot of methods that the Avm does not implement and which do seem to be implementation details rather than genuine API-level methods.
• TransactionResult: need to figure out how much of this should remain in the VM and how much in the API. I'm kind of leaning towards moving all result codes into the API except possibly the failure codes, which may be VM-specific. Or moving some of these up and allowing VM's to define their own failure codes as well.
• TransactionResult should have its fields set ONLY inside the virtual machines, and the kernel should be the consumer of this data. Therefore, the getter is all that needs to be exposed.
• A VirtualMachine should start itself up once you first create it, this should not be part of the API.
• We need a solution for where the newly created contract address is to be generated so that a VM can control this generation and pass it back to the kernel appropriately. Currently the Avm does it in the context and the fvm does not do it but instead receives this from the kernel - the kernel generates it inside its Transaction class.
• From the perspective of the Avm, it probably makes sense to make the following classes POD types for the API: Address, BloomFilter, Log, Context
• The KernelInterface needs to document each method's full scope of functionality precisely so that everyone agrees on it. This is a dangerous place where returning null instead of some other 'invalid' signifier (zero or an empty list, for example) can lead to bugs that internal VM tests don't catch because someone else implemented the interface differently.

[aionick]

I'm going to go ahead and close this issue, it was mainly here to collect insights as we worked through the integration. It will be useful going forward, but we can retrieve it from the closed issues. I suspect there's not much more to add on to this anymore.