Unify ink_env::{eval_contract, invoke_contract}

[HCastano]

It looks like eval_contract is just a special case of invoke_contract but with better performance due to not having to fetch the results of the contract invocation.

From an API point of view, I think it would be more user friendly to provide a single API for cross-contract calls and let the function internally optimize depending whether or not a return type is required by the user.

[ascjones]

Rather invoke_contract is just a special case of eval_contract with a concrete () as the return type. invoke_contract<T, Args> == eval_contract<T, Args, ()>.

I agree it doesn't make a lot of sense to have separate fns which eventually both call invoke_contract_impl under the covers anyway which always attempts to decode the return value. Passing () as a type parameter to eval_contract will be the same thing, making the decoding a no-op.