Consider using `wasi:io/error/error` instead of a custom error resource

[fibonacci1729]

As a bit of early implementation feedback, i found that implementing the host side of things for wasi:messaging/messaging-types/error imposed a bit of a hurdle/challenge.

How would everyone feel to replace the custom error resource defined in this package with wasi:io/error/error.

Alternatively, to make host-side implementations easier to wrangle, i'd suggest isolating out the error type into its own interface (similar to wasi:ios error) which would minimize the host code required.

Wdyt?

[thomastaylor312]

I would definitely prefer its own interface if possible in the options you presented, but I am also rather partial to errors being represented as enums rather than opaque resources. Was thinking about changing that as part of an upcoming PR to integrate some feedback from people

[thomastaylor312]

Heads up @fibonacci1729 that I added error as a variant in #23