Refactor errors in `Result`

[helins]

I believe a simpler approach to Result would be the following one:

• Result has only 2 fields: id and value
• convex.core.lang.impl.ErrorValue becomes an ACell
• Hence ErrorValue is just another ACell value for Result

Less confusing that having 2 extra fields in case of error and abusing .getValue.

[mikera]

I was trying to keep the AExceptional hierarchy separate from the ACell hierarchy because it is mainly an implementation detail rather than a fundamental data structure for the CVM. It is used to implement various internal mechanisms e.g. trampolines. From the CVM perspective, an error is defined simply as having a non-null Error Code (hence the Result design)

[mikera]

In general, I'm not too keen on mixing logical types in one field as in "this value might be a real value, or it might be an error, it's up to you to work out which it is". I think I prefer two fields for less ambiguity.

[helins]

I see, however in practice even as such you have to check for those fields and do some usual error handling. The value might either be an actual value or a string message if I'm not mistaken, so it feels very much like what you describe IMO.

[mikera]

In general, I think clients will need to check for errors after every Convex interaction. I don't think this can be avoided (unless you really don't care what happens to a transaction, but then why did you send it?).

We might be able to improve the API for doing this though (which can potentially be independent of the underlying Result representation).