Implement host function: `svm_account_create`

[YaronWittenstein]

Depends on: #467

As detailed in the SVM Self-Spawn SMIP, we want to add a new flow of Accounts Spawning - the Self-Spawn.

There are two main stages:

• Creating a new Stub Account (I prefer Pending Account or Inactive Account). It should be done when running a Call Transaction (and not via running the ctor of a Spawn Transaction).

• Executing a Spawn Transaction that will activate that pending Account. The criterion of whether a Spawn Transaction will have the default flow or the Self-Spawn one determines whether or not the Principal Address of the transaction is active.

If it's, then it's a default Spawn. Otherwise, it must be in a Pending state, and the transaction will activate it. In any case, if the Principal Account isn't found, then the transaction should be discarded.

One option is implementing a new dedicated host function named svm_account_create. It will receive as input the Address of the new Account to create and its initial balance.

Computing the Address should be done separately.

Funding the new Pending Account will transfer coins from the current Target Account. (of the currently executing Call Transaction) to the newly created Stub Account.

If there is already an Account (Stub or Active) with the given Address - the host function should panic.

fn account_create(env: &FuncEnv, addr_ptr: i32, initial_balance: i64) {
 // Assert that we're not running the `ctor`
 // ...
}

Why not adjust the svm_transfer host function?

It's possible to do so. The reason, I think, it's not ideal is for Gas Pricing. Transferring coins between two existing Accounts should be priced differently than creating a new Account and funding it with its initial balance.

Since we want to give better pricing on compile-time (a requirement for the Fixed-Gas), we might better end up with a dedicated svm_account_create host function.

Of course, it is possible to adjust the svm_transfer to fall back to creating a new Stub Account when the destination account doesn't exist (the current code panics on such a case).

That said, in case we want to support a case where we don't know at compile-time whether the Account exists or not. It seems we need to go for the svm_transfer adjusting path. (the Gas Pricing will be less accurate, but that's the trade-off).