With this all receipts are accounted for within this structure.

Next up will be moving the iteration over receipts to happen internally
within this structure, which would then allow us to also peek, etc.

This now allows introducing some hooks for pipelined preparation into
the receipt execution loop.

It appears that having the contract code access bundled into Externals
wasn't particularly helping with lifting the contract preparation up. As
a demo I have lifted the preparation to happen before the RuntimeExt is
constructed...

This avoids a problem where in order to prepare a contract the NEAR
balances of an account need to be known (in order to construct a
`VMOutcome`) but also where the balance of an account might change by
the time the VMOutcome is materialized to the caller as a result of them
calling `run`.

`method` has been very recently moved into `VMContext` with the thought
that `method` is closely related to the function call arguments which
were already inside `VMContext`. However with `prepare` having been
modified sufficiently to not rely on `VMContext`, `method` has again
moved to be passed through a function argument. Keeping another instance
of `method` inside `VMContext` would potentially allow for value
confusion, as running a different method than what has been prepared is
invalid.

This is not, strictly speaking dead-dead code. It is going to appear in
a future change regardless, but is unnecessary in this PR.