remove unused ExecutionResult::create_address

[poszu]

The address of the spawned program is returned the same way as the results of all contract methods via the ExecutionResult::output.

[lrettig]

A few questions:

1. What happens when multiple spawns occur in a single call, or a single program execution? E.g., imagine a program serially spawning multiple other programs.
2. What happens when a spawn occurs lower down in the call stack? E.g., imagine a program makes an external call that results in a spawn. How does it get the result of that spawn?
3. What happens if both of these occur, i.e., a program makes an external call that results in multiple spawns?
4. What about the case described in this comment?:

athena/ffi/athcon/include/athcon/athcon.h

Lines 394 to 403 in 46a7084

	/**
	* The address of the possibly created contract.
	*
	* The create address may be provided even though the contract creation has failed
	* (athcon_result::status_code is not ::ATHCON_SUCCESS). This is useful in situations
	* when the address is observable, e.g. access to it remains warm.
	* In all other cases the address MUST be null bytes.
	*/
	athcon_address create_address;
	};

This is a nuance involving gas pricing and the cost of state access. In a single transaction, we need to consider the fact that the first time an account is touched (or created), the cost is higher than subsequent accesses (this is what is meant by "warm"). We probably don't need to worry about this for now, but I just want to make sure that we're aware of it.

[poszu]

I can't answer any of these questions as we don't support these functionalities at the moment nor are they designed. However, there is no point in having a hypothetically useful thing "for the future". There's a high chance that, when the time to implement these features comes, we will need to find a different, tailored for our needs, solution anyway.

[poszu]

Let me give it more thought. I think we could return the spawned addresses in every case "normally" by bubbling it up the call stack, if the CALL syscall supported returning results (#36). For example,

1. What happens when multiple spawns occur in a single call, or a single program execution? E.g., imagine a program serially spawning multiple other programs.

This program could return Vec<Address>, which would be available to the caller in results.

2. What happens when a spawn occurs lower down in the call stack? E.g., imagine a program makes an external call that results in a spawn. How does it get the result of that spawn?
3. What happens if both of these occur, i.e., a program makes an external call that results in multiple spawns?

The address(es) could be simply returned from the CALL syscall supported returning values (#36)

4. What about the case described in this comment?:

I don't understand the use case described in the comment. What address would it return if spawning failed? Anyhow, probably the same method could be used (return the address in execution results).

[lrettig]

1. What happens when multiple spawns occur in a single call, or a single program execution? E.g., imagine a program serially spawning multiple other programs.

This program could return Vec<Address>, which would be available to the caller in results.

Only one thing to add: the result of each spawn can already be available to the program performing the spawn, as each spawn host call returns the newly-created contract address. The question of how to surface this to the user is a bit more complex. The other obvious way to do this, aside from a program return value, is logs/events (#92).