A better abstraction is required in order to access the chain state

[ggrieco-tob]

One of the objectives of medusa is to allow easy extensions of the code. I recently created a PR to optimize the gas usage instead of a call to a particular function. While it was not very complicated, the API to query the TestChain object should be improved. For instance, in order to access to the receipt of the last transaction, I had to check the pending block. If there is no transactions pending, I had to look at the last block:

		pending := worker.Chain().PendingBlock()
		var gasUsed uint64 = 0
		if pending != nil {
			messagesLen := len(pending.MessageResults)
			if messagesLen > 0 {
				gasUsed = pending.MessageResults[messagesLen-1].Receipt.GasUsed
			}
		} else {
			blocks := worker.Chain().CommittedBlocks()
			blocksLen := len(blocks)
			lastBlock := blocks[blocksLen-1]
			messagesLen := len(lastBlock.MessageResults)
			gasUsed = lastBlock.MessageResults[messagesLen-1].Receipt.GasUsed
		}

I believe this is inherited from geth and it is not clear for me how to improve it to allow a more uniform access to the latest transactions, but it could be a good idea to improve for future extensions.

[Xenomega]

Good callout. We've had similar discussions with @Jaime-Iglesias . I'll drop some thoughts here stemming from those discussions.

This PR should extend past TestChain and we can provide some nice helper functions for various providers (wrapping ContractDefinitions + deployments to provide methods), features to quickly get receipts, last block, events across multiple blocks, contract deployments/destruction events. Maybe some functions to iterate over execution traces to check if some conditions occurred during execution, etc.

Until we finish the higher level testing API, maybe this should be lower priority. Once we have that, it will be more clear to us what higher level functions would be useful to have. So lets wait to add this just until then, as our testing loop, and testing framework will change and uncover what we should invest into more, and how the API should look.

So maybe we should do a post-high level testing API milestone where we focus on API design, since we should have all the bits we need at that point (easier access to arbitrary shrinking, etc).