Expose underlying JS Errors

[arv]

At the top level in connection.rs when we return a JS Error to JS, we
now extract any possible inner JS error and add it as the cause
property to the JS Error.

Fixes #352

[arv]

this could just return None but by using a match it will be a compile error if the enum changes

[aboodman]

A few concerns with this:

1. This seems like a lot of machinery to maintain going forward.
2. Isn't it a layering violation to introduce ToJsValue all throughout repc?
3. What is the impact on code size?

[arv]

All good questions.

A few concerns with this:

1. This seems like a lot of machinery to maintain going forward.

2. Isn't it a layering violation to introduce ToJsValue all throughout repc?

3. What is the impact on code size?

1. Not sure how to make it less machinery?
2. Maybe we can make it a type parameter?
3. Will have to check. My gut feeling is that it will not impact much. match with enum should map cleanly to the wasm br_table instruction but I'll check later

I think the experience we had with our customer over the last weeks shows that we really need to expose the underlying JS exception for error reporting to be meaningful.

Could it be done in a simpler way? Maybe? Maybe a custom derive would make things easier to use but I feel like figuring out how to do custom derives is more work than it is worth.

[aboodman]

I was thinking about this. I think this is the right approach. If you imagine future non-js host environments, they are all going to have this problem of wanting to communicate the "cause" exception in the host system. Could we sub to_js for to_native which could theoretically someday be more abstract and return e.g., Swift errors? We don't have to actually (and probably underiable to) do this abstraction now -- I just want to do the name and convince myself it's possible to do it later.

[arv]

I'll bring this up to date...