Fixes #216: Unwrap all Trace calls

[sappenin]

Fixes #216 to ensure that any errors in trace methods unwrap and expose the error, by implementing the following:

• Makes the default trace… methods panic on an error.
• Exposes trace_with_result variants for callers that want to handle their own error.

Type of Change

• Refactor (non-breaking change that only restructures code)

Release Note

All trace... calls will now panic if any error is encountered. Because this should never occur, this is not considered a breaking change. If a developer wants to called a trace function and handle the error manually, the trace...with_result variants should be used instead.

[mvadari]

I'm concerned that the proliferation of these types of host functions will mean that the WASM code that is generated is much more bloated than it needs to be.

[sappenin]

I'm concerned that the proliferation of these types of host functions will mean that the WASM code that is generated is much more bloated than it needs to be.

I think you meant to say, "helper functions" instead of "host functions"? If so, it's a fair point and I think I have three thoughts to help alleviate any worry:

1. All of these helper-functions are optional (developers don't need to use them), so if code bloat is a worry for a developer, they can always opt-out and just use host functions directly. The compiler shouldn't include these functions in final bytecode if they're unused.
2. This PR doesn't introduce any new helper function per-se (technically, it does introduce a new function, but this function is actually just a preferred style of the old variant). This means two things in the context of this PR: First, we don't have any breaking changes (because the old style is still present and available) and Second: keeping the old style means that a developer that doesn't want this "auto-unwind" feature can instead choose the other style (e.g., see trace_with_result which will give access to a Result instead).

[sappenin]

This PR is no longer in-scope. Please see https://github.com/ripple/xrpl-wasm-std for now and feel free to re-open a PR like this one in that project, if appropriate (we may revisit a CLI in the future, but for now are continuing work on the XRPL WASM standard library in that project).