feat: must use CallExecution* type

[ChaoticTempest]

This is not necessarily an API-breaking change but semantically would change how errors are being bubbled up. This adds the #[must_use] to CallExecution* types so that the users are forced to handle it. The previous way of turning the CallExecution* type into a Result was not so great since we'd end up consuming the CallExecution* info along the way if a user wanted to handle the error but also have the details of the execution.

Added ok() and assert_ok() methods to use the CallExection* objects if the user does not care about the results contained within them. They'll still have access to the execution info regardless

[ChaoticTempest]

This should also resolve #138 and #131

[ChaoticTempest]

@itegulov @austinabell Let me know what you guys think of this now. CallExecutionDetails just has executed() so people can forward the errors up for convenience, ok()/err() to explicitly handle the errors with the details included

[austinabell]

Going to open another issue because the types that are forwarded from the RPC types seem very unintuitive to use. So unclear how to proceed, for example, we are awaiting transactions to be fully completed, but we still have the intermediate execution statuses nested within the CallExecutionDetails structure.

Opened issue: #183

[ChaoticTempest]

New changes based on #183. Also took the liberty of renaming CallExecution* to be just Execution* since they're not purely just execution details from a call.

So after this, we have ExecutionFinalResult to allow us to do into_result() -> Result<ExecutionSuccess, ExecutionFailure>. Also note that I had ExecutionFinalResult could have just been a type alias of ExecutionFinalResult like the Success and Failure types, but #[must_use] would end up being applied to success/failure types as well which wasn't ideal.

[austinabell]

handling execution errors there definitely seems like an improvement, just left some comments for small questions about details.

[ChaoticTempest]

@austinabell think we should be good to go with this one. I'll merge this one right now, and if there's anymore concern, we can address in another PR