Add ErrorMessage enum, start using it

[Manishearth]

This is a step towards #113. I didn't finish converting all of the enums, just some of them to give an idea of what this might look like.

This error enum will be private for now: It's primarily encompassing messages, and will wrap all static string messages. The non-static ones I think we should convert to something else at the boundary, potentially logging them with a feature.

Once this is fully filled in, I plan to:

• Replace the .msg field with the enum
• Add to/from integer methods for the enum, exposed as helpers on TemporalError
• Use the integer value in FFI TemporalError.

This is not primarily designed with user matching in mind: it can be matched by the user, but I don't think this is the right level of granularity. Instead, we can use this error message ontology to map to a more structured public error ontology if we want. Basically, in the medium term we can have a RustErrorKind that can be internally obtained from ErrorMessage, which we expose to the user.

Thoughts?

[nekevss]

Mostly curious what @jedel1043 thinks as he had a much more vocal stance.

I'm a bit mixed, but leaning towards this is fine. I think my mixed opinion comes mostly from it being an intermediary.

[Manishearth]

Yeah, it's an intermediary, but at the very least it's an intermediary that lets the error enum be Copy, which is super nice.

[jedel1043]

Hmm, I'm thinking maybe this should be moved to temporal_capi instead, but I'm also thinking that it would be nice to have an enum representing all possible error messages, then put all the additional error data on TemporalError...

Yeah, I like this approach. Let's go with this and see how it would fit on the Rust side. We can still do more adjustments when we migrate the non-static error messages.

[jedel1043]

Looks good!

[Manishearth]

Wonderful, I'll try and fill in the rest